From Quentin Carbonneaux to ~mpu/qbe
On Sat, Nov 30, 2024, at 19:40, John Nunley wrote: > I am interested in adding i386 support to QBE. However before I go ahead > with that I realized that I need to figure out what the proper approach > for handling the "l" typeclass is. I can see two options. > > 1. Throw an error when the "l" typeclass is used for 32-bit targets. > Leave the onus for lowering long integer operations on the frontend. That'd be okay I think. > I believe 1. would be the preferred option since I think cproc already > has code for lowering "long long" on 64-bit targets. That being said I > wanted to confirm.
From Quentin Carbonneaux to ~sircmpwn/hare-dev
On Sat, Nov 9, 2024, at 11:42, Roland Paterson-Jones wrote: > I think an obvious "fix" is to NOT clear the types at the start of > every input file, which I'll play with a bit... Seems ok. If it works!
From Quentin Carbonneaux to ~mpu/qbe
Hey Rosie, Sorry for the late answer. Thanks a lot for reporting these issues! The last commit on master should fix all of them. On Tue, Aug 20, 2024, at 00:28, Rosie wrote: > 1. Floating point numbers This one was fixed a while back, when we realized a simplification by Michael was actually breaking the example you provide. > 2. Buffer with undeterministic size being returned from a function
From Quentin Carbonneaux to ~mpu/qbe
On Mon, Sep 30, 2024, at 19:09, John Nunley wrote: > I'm not sure if it would take more effort than it's worth, or if it > would be better as an external branch to 'master', but it may be > worthwhile to make sure QBE builds with MesCC, to compile the cycle for > the "Maxwell's Equations of Software". I think that to "compile the cycle for the Maxwell's Equations of Software", I'd rather have MesCC be a bit better at understanding the C programming language :).
From Quentin Carbonneaux to ~mpu/qbe
On Fri, Sep 13, 2024, at 08:25, John Nunley wrote: > ``` > /tmp/out.S:10: error: unknown opcode 'callq' > ci/test.sh: error on line 21: "$CC" /tmp/out.S ./src/libdozer.a -o /tmp/out > ``` I assume the issue is the 'q' suffix in the instruction name. You can remove it by editing amd64/emit.c. If that is the only issue I'm happy to remove it.
From Quentin Carbonneaux to ~mcf/cproc
On Wed, Sep 4, 2024, at 01:04, Roland Paterson-Jones wrote: > This leads to neater code - single instruction, no more > blocks, and facilitates further QBE optimisations. Yep I wanted to do that but did not. I'll merge that in my patch and re-send it.
From Quentin Carbonneaux to ~mpu/qbe
On Thu, Aug 29, 2024, at 11:10, Roland Paterson-Jones wrote: > Not sure if anyone has noticed, but Hare perf - according to > "HARETEST_INCLUDE='slow' make check" - appears to get a significant > boost (~20% overall) from Quentin's latest master patch. Nice! It was motivated by coremark and yielded some gains on my laptop, but I cannot reproduce them on my desktop :P. It also generates sweeter code for small functions that people will naturally try with qbe, so it's a PR stunt at the same time!
From Quentin Carbonneaux to ~mpu/qbe
On Tue, Aug 13, 2024, at 17:36, Jakob Kenda wrote: > I'm currently rewriting my compiler to use QBE and I decided to extend > it with debugging info. > I noticed it was already half implemented so I decided to finished the > implementation. Hi, what do you mean by "half implemented"? It seems like what your patch does is allow line information at toplevel however I do not see how this is helpful. It seems to me that having dbgloc inside functions is enough (and it has been enough for Hare anyway). > A "dbgfile" instruction was already present but undocumented, and i > added a ".loc" instruction. > It would be good to include these instructions in documentation, let me
From Quentin Carbonneaux to ~mpu/qbe
On Fri, Aug 2, 2024, at 13:39, Alexey Yerin wrote: > Clang incorrectly optimizes this negation with -O2 and causes QBE to > emit 0 in place of INT64_MIN. I pushed your patch on master. Clang is not "incorrect" unfortunately, since the overflow is UB. That being said, wow, spooky! I thought this would never happen. I'd like to get to the bottom of it. Can you give me some details on your compilation settings (clang version and target arch)? On my machine, your patch does not change the assembly generated. Thanks for reporting and fixing!
From Quentin Carbonneaux to ~mpu/qbe
On Wed, Aug 7, 2024, at 10:55, Roland Paterson-Jones wrote: >> For if-conversion of Kl values I would like to generate a Kl result >> straight from cmp ops, rather than adding an extra ext instruction. > > This should just work Yes, if it does not it's a bug :).