- User Since
- Sep 26 2016, 7:58 AM (237 w, 2 d)
Mon, Apr 12
Wed, Apr 7
Here is a reduced reproducer that goes into infinite loop with this patch:
I've seen problems with infinite loops in InstCombine after mergin this patch downstream:
Tue, Apr 6
Seems like there is little interest in this, but I was not sure really who to call for review from the beginning. Please let me know if you aren't interested in reviewing this by removing yourselves as reviewer (that way I know I need to find some other candidates).
Mon, Apr 5
Sat, Apr 3
I pushed my workaround for Z3 here: https://reviews.llvm.org/rGd66f9c4f1e83e69abf75f97cb5f8fd1dc9422357
Hopefully that will make our bots happy again.
Not sure if it is the correct thing to do, but a patch like this seem to help for the Z3 problem:
So this seem to break more things than just Z3 builds (considering D99829). Should we revert while sorting out these things. I'm kind of lost here, just know that our integration bots are stuck and they've been failing since this patch landed on April 1.
Fri, Apr 2
Unfortunately out downstream bots started to fail with this commit (building the main branch).
Wed, Mar 31
This one actually landed as https://reviews.llvm.org/rG2f8f01dcb3d43d2fb1149fc8988e61f93f9064f5
Mon, Mar 29
Here are some diffs I get depending on having this patch or not:
In our case we always do a clean build on bots so I'm not sure if it's the same issue.
We are also seeing problems with this when rebasing downstream. A somewhat strange thing was that it worked if I invoked the build a second time without removing my build directory in between. But with at clean (non existing) build dir I got failures.
I thought that it maybe was something wrong with my merge (or just a downstream problem), but if others also see problems with this then maybe not. Anyway, if I revert this patch things works fine again.
Fri, Mar 26
Wed, Mar 24
Tue, Mar 23
Mon, Mar 22
My users have found problems with miscompiles that seem to originate from this patch.
Fri, Mar 19
Minor update (using a bit more graphical examples instead of only text, even though it isn't exactly ascii art as someone suggested).
Wed, Mar 17
Tue, Mar 16
Changed the wording quite a bit. Getting rid of references to C ABI etc.
I'll try to make some progress here.
Mar 14 2021
Mar 12 2021
Mar 11 2021
Update code comments (those comments depends on landing D98410 first).
Mar 9 2021
Mar 7 2021
Mar 4 2021
I guess it wouldn't hurt if the pass names generally would match with the DEBUG_TYPE.
If you need this I'd rather "add the needed support" than doing it as a revert (although nice to get the history here in the review). To be more specific; I would let RegisterInfoEmitter provide the size in bits rather than the mystierious "/8" that for example results in a 1-bit register being reported as having size 0. And I'd get rid of the redundant "getSize()" method. And the change to the code comment in TargetInstrInfo::getStackSlotRange could probably be skipped.
Mar 1 2021
Feb 19 2021
Feb 10 2021
Feb 8 2021
Feb 7 2021
Feb 5 2021
I think the problem with loop metadata not being handled properly is a bug (that also could impact performance negatively) , so this is a quick fix (but I guess it could be possible to handle transition of metadata to the new latch with some effort if the transform is beneficial).
Feb 1 2021
Jan 31 2021
Add tests using big endian datalayout.
Jan 28 2021
Jan 27 2021
Btw, as far as I know @uabelho hasn't found any problems with the fix. And except the checks in the test case I think it looks like a nice fix (avoiding miscompiles).
Jan 26 2021
Update correct version of test case (without the FIXME).
Jan 22 2021
Jan 21 2021
@lebedev.ri : I think I need your blessing as well on this, considering your earlier concerns. Is it still just confusing? (I doubt that we want/can replace all uses of getCharWidth/getIntWidth etc in clang with integers)
Updated to add CharTy to the CodeGenTypeCache (based on review feedback).
Jan 20 2021