User Details
- User Since
- Oct 27 2012, 6:35 AM (429 w, 1 d)
Today
This should probably be split up into BasicAA (+unit test), MemoryDependenceAnalysis(?), and GVN patches.
Sat, Jan 16
Please precommit tests.
This is more like it.
InstCombine is a canonicalization pass, and by design it must not make use of TTI.
This should be fixed by a reverse transformation in backend.
Fri, Jan 15
Tests missing
Seems about reasonable to me.
Thu, Jan 14
Why do we even want to bend over backwards and try to handle broken code correctly,
at the cost of regressed performance for everything,
instead of just adding defensive asserts against such problems,
and letting/telling the user fix the code?
Wed, Jan 13
So are the compilation time issues reproducible with vanilla llvm, or only in your local branch?
If latter, shouldn't the fix (which isn't hiding the verification under) belong to the branch?
Thanks for the feedback. Do you suggest to implement this as an another optimization after SwitchToLookup in SimplifyCFG?
I'm not really sure where it would fit best. Assuming it doesn't require changing CFG
this might even be eligible for InstCombine, but adding it into simplifycfg is a safe bet i guess.
Tue, Jan 12
@aaron.ballman thank you for taking a look!
@NoQ thank you for commenting.
Then, tangential question: shouldn't this simply be a separate transformation, to turn non-PIC-friendly (non-relative) LUT's into relative LUT's?
Mon, Jan 11
Sorry for the delay.
Sun, Jan 10
What specifically is having problems after that transformation?
Fri, Jan 8
Why must values have pointer types?
Thu, Jan 7
This seems to be missing test coverage.
Tue, Jan 5
Fixed by 29ca7d5a1ad968c371124b8d82edd8d91eee7b4f, thanks!
I do not understand the example in https://bugs.llvm.org/show_bug.cgi?id=48529
By "intent", are you saying that the canonicalization of commutative ops
is causing the code to be miscompiled, leading to different observable side-effects?
Hi,
Mon, Jan 4
Looks good to me, thanks.
Sun, Jan 3
I'm being dense here, sorry. I thought benchmark is usually built with -std=c++14,
but as per llvm-project/llvm/utils/benchmark/CMakeLists.txt, that is not the case.
So i'll just reland this.