rolandpj@rolandpj-VivoBook-ASUSLaptop-X515DAP-M515DA:~/src/hare$ make
HARE .bin/haredoc
86/136 tasks completed (63%)
qbe:/home/rolandpj/.cache/hare/home/rolandpj/src/hare/net/ip/60d084799b439aacefc152dd14ec8b0c7210fa4d6ae97153924703ea117e4889.ssa:4045:
ssa temporary %.1950 is used undefined in @.1934
qbe for net::ip (/home/rolandpj/src/hare/net/ip) exited with status 1
make: *** [Makefile:54: .bin/haredoc] Error 255
---
Unfortunately this is not covered by 'make clean; make check' on a
previously built repo, which is why I didn't notice it before.
Can anyone from hare teach me how to do a completely fresh build
(including haredoc?) in an existing hare repo?
Again will investigate... apologies
R
On Wed Jul 17, 2024 at 3:31 PM CEST, Roland Paterson-Jones wrote:
> Can anyone from hare teach me how to do a completely fresh build> (including haredoc?) in an existing hare repo?
If you already have a working hare binary, hare cache -c. Otherwise rm
-rf ~/.cache/hare (or whatever your cache dir is).
> If you already have a working hare binary, hare cache -c. Otherwise rm> -rf ~/.cache/hare (or whatever your cache dir is).
Thanks! And speaking of which, where can I find a corpus of hare
software to improve test coverage of my QBE patches?
Benchmarks in (pure) hare would also be fantastic.
I don't think we have much by way of benchmarks (though you could run
hare test with `HARETEST_INCLUDE=slow` to enable "slow" cryptography
tests).
We have a general "project library" here:
https://harelang.org/project-library
> https://harelang.org/project-library
Nice! I can likely fabricate something useful for perf testing from at
least the lz4 and other compression stuffs.
> rolandpj@rolandpj-VivoBook-ASUSLaptop-X515DAP-M515DA:~/src/hare$ make> HARE .bin/haredoc> 86/136 tasks completed (63%)> qbe:/home/rolandpj/.cache/hare/home/rolandpj/src/hare/net/ip/60d084799b439aacefc152dd14ec8b0c7210fa4d6ae97153924703ea117e4889.ssa:4045:> ssa temporary %.1950 is used undefined in @.1934
Ok, this is a very interesting issue (use before def) and something I
was concerned about previously but it never seemed to happen in
practice.
Essentially GCM is hoisting a bunch of instructions into an earlier
block where the hoisted instructions come from various other blocks,
and some of the hoisted instructions depend on other instructions
hoisted to the same block.
The sched() function in GCM copies hoisted instructions in RPO
(reverse-post-order) of the source block. Almost all the time this
results in a valid final instruction ordering in the target block;
however in this particular case the current code is over-optimistic
(i.e. just wrong) and there is at least one hoisted instruction that
ends up ahead of the instruction defining one of its arguments.
In this specific case, RPO doesn't work for a correct final schedule
because GVN happens to dedup instructions in such a way that the final
scheduling is in the wrong order. Of course it's expected to have an
invalid "schedule" after GVN; however GCM is supposed to fix this up
(while also moving instructions around in general).
Unfortunately I'll need to think about this a bit - basically we need
some kind of instruction dependency sort/ordering in GCM sched() but
I'm not sure right now what the neatest way of doing this is...
---
Aaaaand, incidentally the instructions involved in this case are
actually trivial field offset address calculations (add <base>, N)
used (only) for subsequent load/stores, which is something I've
(previously) added some code in GVN/GCM to avoid as it's generally a
bad idea (most architectures can do a constant offset load/store in a
single instruction quite happily). Aaaand I now see that I've
forgotten the "blit" case of the same general "bad-for-GCM" trivial
offset calculation case, and the blit case occurs a whole bunch in
this code. In other words GVN/GCM is actually doing some stupid things
here apart from just being buggy, so it was a good test case to look
at more closely :)
R