- User Since
- Apr 5 2019, 5:06 AM (81 w, 1 d)
Sun, Oct 4
Sat, Oct 3
It is possible DCE will handle the null check with "nonnull" attribute, so add the test first.
Fri, Oct 2
This pass should recognise the nonnull attribute, as it is analyzing against null.
Jul 19 2020
Jul 10 2020
Jul 8 2020
Jun 25 2020
This was commited
Jun 24 2020
It can be done with xor to produce a zero vector, however I can't get the code-gen to generate something that doesn't use the TOC.
Jun 17 2020
Also non-powers-of-8 can be handled https://godbolt.org/z/6Nww6p
Jun 16 2020
What about shr and ashl?
Jun 9 2020
Jun 8 2020
update tests so review is not distracted from another optimization bug
Jun 7 2020
Jun 5 2020
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