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 :).
From Quentin Carbonneaux to ~mpu/qbe
On Thu, Aug 1, 2024, at 17:45, Rosie wrote: > One thing I'm still confused about though, is why this: > > ```qbe > %foo.addr =:Foo call $getFoo() > %foo.copy =:Foo copy %foo.addr > ``` > > throws an exception, but this: > > ```qbe > %foo.addr =:Foo call $getFoo() > %foo.copy =l copy %foo.addr > ```
From Quentin Carbonneaux to ~mcf/cproc
Hello,
This patch is a minor refactor of code generation for
branch conditions. Until now branch conditions were
treated just like any other expression. With the
present patch, and its associated modest increase in
complexity, branch conditions are compiled in a
context where the two targets (taken / not taken) are
available. This leads to slightly simpler qbe IL.
The change I was most concerned about is the different
compilation of TLNOT. Rather than turning it into a
comparison with zero early, we keep it in the IL and
defer to funcjnz later on. I tested it with pointers
[message trimmed]
From Quentin Carbonneaux to ~mpu/qbe
On Fri, Jun 21, 2024, at 11:24, Rosie wrote: > which does not return stack allocated memory, the incorrect instruction > is still emitted. Oh yes sure, I'm not saying qbe is right.
From Quentin Carbonneaux to ~mpu/qbe
On Thu, Jun 20, 2024, at 22:03, Rosie wrote: > but I would love to know whether this is an issue I caused due to > incompetence or due to QBE screwing up codegen. qbe should not generate invalid asm. That being said, the way you allocate memory on the stack of a function and return it is unsafe. You should consider that all the pointers you got from a "alloc" instruction are invalid once the function has returned. I will try to fix the asm generation bug shortly.