- User Since
- Mar 4 2015, 5:47 AM (318 w, 5 d)
I have been investigating the behavior of struct path tbaa and new struct path tbaa. Based on what I could find, returning MD is the correct thing to do in struct path tbaa.
@wsmoses I will not have a solution today, but hopefully tomorrow. I would appreciate if you could help review then. Thanks.
FYI: I am looking into an alternative fix.
Fri, Apr 9
Please do not commit this yet. A ping would have been appreciated.
Wed, Apr 7
On the other hand, a ptr_provenance path skips pointer computations. We might need to refactor this code to separate the 'based on' part, so we can first check the ptr_provenance path (if available), and when that is not conclusive,
we can fall back to the original pointers (that also contain GEP information etc).
I am wondering how this will interact with the ptr_provenance changes/full restrict changes. In the full restrict version, V1AAInfo and V2AAInfo are used in BasicAAResult::aliasCheck to decide if we can see trough noalias intrinsics or not.
Fri, Apr 2
Mon, Mar 29
- Deprecating LLVMIntrinsicCopyOverloadedName
- Added release note.
Dropping in favor of D99173.
Thu, Mar 25
Wed, Mar 24
- Introduced LLVMIntrinscicCopyOverloadedName2(...), Introduced `getBaseName(...)'
Tue, Mar 23
Mon, Mar 22
Sun, Mar 21
Sat, Mar 20
Thanks for taking the initiative !
Fri, Mar 19
Rebased. Moved ~PredicateInfo() to header.
Rebased. Modified langref and test according to comments.
Mon, Mar 15
Thank you for all the help with the review !
Mar 10 2021
Fixed an unwanted reversal of instructions shown in the testandor.ll test.
The pr48340.ll test was also moved to the X86 directory.
Changed according to comments.
Mar 9 2021
- added reference to and testcase for PR48340
Mar 1 2021
This is an attempt to trigger the discussion. This patch fixes the observed issue, but it might not be the right place to do ?
Feb 22 2021
I am now tempted to think that any same-scope usage of llvm.experimental.noalias.scope should be avoided..
For something like loop-unswitch, it is not 'wrong' conceptually to have the same scope, but always cloning the scope
should be safer, with, in most cases, no impact on code quality.
Thanks for taking care of this !
Feb 18 2021
Feb 2 2021
Any chance an updated version of this improvement can be added to bugpoint ?
At https://llvm-compile-time-tracker.com/index.php?config=O3&stat=instructions&branch=dobbelaj-snps/perf/InlineFunction_same_inst_20210202_01 there is a comparison of two possible approaches.
But I do not have the impression that it makes a big difference for these testcases.
Feb 1 2021
Jan 29 2021
Note for those that have not been following the LLVM AA Technical Calls: we have introduced part of the infrastructure needed for full restrict by focusing on fixing https://bugs.llvm.org/show_bug.cgi?id=39282 (See D93039, D93040, D92887, D94306).
Jan 27 2021
Adapted to comments.
Jan 26 2021
There seems to be a problem with bad duplication in the MemorySanitizerLegacyPass.
Jan 25 2021
I disabled the dominance check by default in rG3b5d36ece21f. Several buildbots show examples where this triggers, indicating there are still passes not taking care of proper handling the noalias scopes.
Adapted to comments.
For a stage2 release build and the test-suite, the largest amount of noalias scope decls for a function is 1075 (triggered by llvm/unittests/ADT/SmallVectorTest.cpp). Everything else is <1000. The largest amount of same scope declarations seen was 5.
For what it's worth, the number '1000' comes from experiments triggering the worst case behavior. With 1000 basic blocks and scope declarations, the time for parsing and checking on my testmachine was roughly 0.1 seconds. (Going to approx 1 second for 4000 blocks and declarations).
Jan 24 2021
Will you do the flip or shall I do it ?
Small refactoring as recommended by @jdoerfert
Thanks. I'll still do the small refactoring recommended by @jdoerfert and then do the commits.
Use NoAliasScopeDeclInst. Only analyze non-debug instructions with metadata. (*1)