The patch adds new member MaybeEVL into InterestingMemoryOperand to represent
the effective vector length for vp intrinsics. It may be extended for some target intrinsics in the future.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1467 | This looks wrong? What does the bitwidth have to do with the *value* of EVL? | |
1494 | I may be missing something here, but isn't EVL just an upper bound on the loop? If so, maybe we shouldn't use for the ForEachLane variant and should instead have a variant which takes End explicitly? |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1494 | Agree. I am too conservative to change the original code. |
Create a new interface SplitBlockAndInsertForLanes, similar as
SplitBlockAndInsertForEachLane but have input argument to control end index.
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1491 | I believe this case should be a trunc. | |
1497 | I don't believe there's anything preventing AVL from being 0 here right? If so, this code is wrong. The routine you're calling has a (documented!) assumption that End > 0. To reuse, you need to add the loop guard and remove that assumption. | |
llvm/lib/Transforms/Utils/BasicBlockUtils.cpp | ||
1641 | It's this call where a dynamically zero End becomes problematic. |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1497 | Thank you for pointing my mistake. I am not positive to remove End > 0 assumption from SplitBlockAndInsertSimpleForLoop because it is used in MemorySanitizerVisitor::paintOrigin and there should not a loop guard to test End. |
This update does,
- Only check whether EVL is zero when EVL is not nullptr. It helps not generate redundant zero check for non-EVL InterestingMemoryOperand.
- Clean up my patch.
I am sorry for that the quality of the patch was terrible. I guess it was due to
that I was too rushed to land the revision before my military educational
recall. It's reasonable that no one wanted to review the terrible patch.
I promise that I will improve the quality of my succeeding patches in LLVM.
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1477 | Can we use IB.CreateZExtOrTrunc(EVL, IntptrTy) and remove the ifs? | |
1481 | extacting -> extracting | |
llvm/lib/Transforms/Utils/BasicBlockUtils.cpp | ||
1670 | Why do we need to keep setting the insertion point every iteration? Will that cause the last index to be checked first? Is there a test case for constant evl. I didn't see one. |
llvm/lib/Transforms/Utils/BasicBlockUtils.cpp | ||
---|---|---|
1670 |
This is to follow the SplitBlockAndInsertForEachLane(ElementCount, Type *, Instruction *, std::function<void(IRBuilderBase&, Value*)>). And the old one is to follow the legacy code.
I think it won't because the letter index will be inserted to the back of the former index.
Fixed vector masked.load will have a constant evl here. store.v4f32.1110 in llvm/test/Instrumentation/AddressSanitizer/asan-masked-load-store.ll is an example. |
llvm/lib/Transforms/Utils/BasicBlockUtils.cpp | ||
---|---|---|
1670 |
You're right. InsertBefore is still after whatever the previous iteration inserted so it didn't really change the insertion point.
|
llvm/test/Instrumentation/AddressSanitizer/asan-vp-load-store.ll | ||
---|---|---|
30 | __asan_load4 needs the input address is 4-bytes aligned. I will refine the test to check that. |
@reames Do you have another concern about the revision? I will land the revision this weekend if the revision does not have comment needed to address. Thank you.
This looks wrong? What does the bitwidth have to do with the *value* of EVL?