- User Since
- Sep 5 2017, 3:03 AM (106 w, 4 d)
Jul 9 2019
Addressed Serguei's comment. Serguei, could you please submit this patch? I don't have permissions to submit patches yet.
@skatkov, could you please submit this patch? I don't have permissions to submit patches yet.
Jan 23 2019
Sep 14 2018
Jun 5 2018
Jun 1 2018
May 17 2018
Without this patch following code leads to a crash
entry: ptr = getPtr() br exit
Jan 29 2018
I wonder is it possible to handle this two instructions, GEPs, bitcasts, loads, and other in findBaseDefiningValue to avoid code duplication and such oversights?
Dec 22 2017
Added some new comments.
Dec 21 2017
Dec 19 2017
"merge" now replaced with "derive" in comments, example in FIXME become a bit less confusing, added new test (with XFAIL) for that FIXME.
Dec 11 2017
Comments slightly clarified.
Dec 9 2017
Dec 8 2017
Dec 6 2017
Dec 4 2017
Corrected the comment.
Dec 1 2017
Amended some comments, replaced lambda's wildcard capture list with explicit one, made isNotExclusivelyConstantDerived static function (to use it in lambdas without capturing).
Nov 30 2017
Now the branch where valid defs of unrelocated pointers are skipped is the first one.
Nov 29 2017
Changed order of the verification traversal to RPO.
Algorithm rewritten, new tests added.
Nov 23 2017
One crash was found during testing.
Nov 22 2017
Add message to assert.
Made logic around getImmediateBasePointer/isDerivedPointerDef more consistent.
All tests now have comments, one redundant test removed, one new added. getBasePointer now works more correctly and getImmediateBase now is the only place where we need to specify which instructions can produce derived pointers.
Nov 21 2017
Oct 19 2017
I've done clang bootstrap with this patch and gathered SCEV statistics: maximum number of SCEVs alive simultaneously is 209373; assuming sizeof(unsigned)==4 it's ~0.8MiB overhead.
Oct 6 2017
Oct 5 2017
Oct 3 2017
Now sinking of unordered atomic loads from constant/invariant memory is allowed, corresponding test case added.
I am going to expose SafetyInfo in follow up patch.
Sep 29 2017
Sep 7 2017
LoopSink uses canSinkOrHoistInst from LICM to check whether instruction can be sunk or not. This check rejects all loads with isUnordered() == true (see http://llvm.org/docs/Atomics.html#atomics-and-ir-optimization). It looks like "unordered" atomics are handled in a right way: they are never sunk into loops.
Sep 6 2017
Actually the answer is here: https://llvm.org/docs/Atomics.html#notatomic