- User Since
- Aug 18 2016, 4:39 AM (135 w, 4 d)
Thanks Eli. In the case LastInstFound == BB->begin(), we have to renumber all
instructions after removing LastInstFound, so there is no need to manually number
the next instruction with 0.
Thanks Eli, I did not realize that there are quite efficient ways to compute the
expressions other than splitting it up and dealing with the even/uneven cases
For DSE, it seems quite straight-forward to preserve OrderedBB (we just remove instructions or replace existing ones with another one). I've added D59789 sketching that. This could be a stop-gap until this patch gets through.
Fri, Mar 22
I've bisected https://bugs.llvm.org/show_bug.cgi?id=41203 to this commit, which seems to cause crashes when building the test-suite with AXV512.
Thu, Mar 21
Ping. @hfinkel did my response make sense?
Ping. This applies the same solution as D59211 to a different case.
Wed, Mar 20
Tue, Mar 19
Thanks for all the feedback!
Reduce number of dbg value calls to 4000.
Add test generated using Python and set size to 0.
Mon, Mar 18
On a first look, the patch looks useful! Any chance to provide the follow-up patch that uses it as well? that would be helpful to see the bigger picture. Also, are you seeing any benefits by preserving the state?
Fri, Mar 15
Thu, Mar 14
Unfortunately this requires at least 64k stores to trigger AFAIK. It is triggered by the same input as D56740. I could try to reduce it, but I am not sure if such a big test case would be valuable?
Tue, Mar 12
Another case similar to D59211
Mon, Mar 11
Use wrapping arithmetic
use wrapping arithmetic
Looks like at other places we cast one operand to uint64_t and then assign the result to int64_t. Given that the operations reflect formulas based on IR types, I guess that's valid? The LangRef does not explicitly mention the behavior of signed overflow for add & co, but given that it is using 2's complement, it should be defined, right?
Fri, Mar 8
Thu, Mar 7
Hi Dave, do you plan to commit this anytime soon?
Wed, Mar 6
Use helpers from CheckedArithmetic.h for overflow checks, split out tombstone issue.
Tue, Mar 5
Just realized this went one step too far up the chain. The underlying object is the loaded value from the stack, but we cannot return that from GetUnderlyingObject, because it does not have a pointer type. I'll try to think of something else.
This partly addresses https://bugs.llvm.org/show_bug.cgi?id=40735
LGTM, given we already do the same for GenericScheduler. Please wait a bit with committing, in case there are additional concerns.
Mon, Mar 4
Thanks Eli! I've updated the message to say unrecognized, which sounds better to me too.
Thanks Sam! Looks like I copied the test without updating them....... Should be fixed now
Fix do_not_sink_nonfree_* tests to actually test what they are supposed to.
Sun, Mar 3
Sorry for the long delay....
Updated to catch more cases. This now fixes 4 fuzzer failures