- User Since
- Apr 5 2019, 5:06 AM (42 w, 2 d)
Oct 24 2019
Are predicated vector instructions not just a special case of DemandedBits? Why can't we leave out the .vp. intrinsics, and just generate the predicate with DemandedBits? That way you do a predicated vector operation like so (in zig): As the example makes clear, this optimization would have to be guaranteed in order for the generated code to be correct (as the predicate avoids a divide-by-zero error).
Oct 14 2019
The Zig language doesn't really want to have to special-case this conversion, and would like to see this patch be revisited. It seems to me like some of these reviews were almost accepts. https://github.com/ziglang/zig/issues/3282
Sep 18 2019
Jul 2 2019
My point is that most languages these days that intend to be compiled to machine code want compatibility with the C ABI, and randstruct will be part of that (and can be made compatible between languages by sharing the seed). LLVM knows what a struct is.
I think the essential functionality of this patch should be in LLVM and not Clang, so that all front-ends can benefit. Too many generally useful things are in Clang when they should be in LLVM (e.g. C ABI for ARM and x86; ranged switch statements). I opened an upstream bug to discuss this. https://github.com/clang-randstruct/llvm-project/issues/52
I think the essential functionality of this patch should be in LLVM and not Clang, so that all front-ends can benefit. To many generally useful things are in Clang when they should be in LLVM (e.g. C ABI for ARM and x86; ranged switch statements). I opened an upstream bug to discuss this. https://github.com/clang-randstruct/llvm-project/issues/52
Oh sorry, wrong bug.
Jun 14 2019
This will be put directly into LLVM-IR, as llvm can't inline it otherwise anyways.
This optimization is not really worth it, for the amount of effort needed to implement it.
Jun 13 2019
fix tests when building tests for ALL architectures
Jun 12 2019
Jun 11 2019
Jun 4 2019
May 26 2019
Yes, can you revert them. I really am not very skilled with svn.
use saturating multiply
this should use saturating multiplication
May 22 2019
remove line nikic mentioned
May 19 2019
May 13 2019
I'll get rid of the leftovers.
comment didn't get included.
I am going to drop this as this optimization really belongs in visitGEP, same with the bitmask code in this file.
May 12 2019
The backends seem to be able to handle "illegal types", even if they couldn't before for this.
review. Also update a few more tests.
May 10 2019
May 9 2019
I like that this also optimizes the case where C is a not
There is no documentation specific to the #include directive. https://docs.microsoft.com/en-us/cpp/preprocessor/hash-include-directive-c-cpp?view=vs-2019
May 4 2019
May 2 2019
May 1 2019
It's not the end of the world, but would mean that we would need to know that the shift amount is less that 256 as far as I understand.
It is certainly not safe to do in LLVM-IR, but there has to be some point at which this can be done, and at this point it is still easy to match the pattern (although it does not match the -O0 pattern with an icmp instead of a select).
no longer depends on cttz transform
Apr 30 2019
the old shifting code could create a invalid shl 32/64
there are no problems, as we can just lower fshr down to what I replaced