[PATCH] D64451: [PoisonChecking] Validate inbounds annotation on getelementptr where possible
Philip Reames via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Aug 21 13:21:53 PDT 2019
reames marked 3 inline comments as done.
reames added a comment.
Address comments in advance of patch refresh.
================
Comment at: lib/Transforms/Instrumentation/PoisonChecking.cpp:217
+ for (unsigned i = 1; i < GEP.getNumOperands() && IsNonNegativeOffset; i++)
+ IsNonNegativeOffset &= isKnownNonNegative(GEP.getOperand(i), DL);
+
----------------
jdoerfert wrote:
> While I now thing this is correct, we might want to make it less restrictive using existing functionality to accumulate and strip pointer stuff, e.g., along the lines of:
>
> ```
> const Value *Base = GEP->stripAndAccumulateConstantOffsets(const DataLayout &DL,
> APInt &Offset,
> bool AllowNonInbounds);
> IsNonNegativeOffset = (Base == Obj) && Offset >= 0;
> ```
>
Your proposal is less powerful than the existing code as it's restricted to constants where the current code is didn't. Did you have a particular missed case in mind?
================
Comment at: lib/Transforms/Instrumentation/PoisonChecking.cpp:234
+ "upper.limit");
+ Checks.push_back(B.CreateICmp(ICmpInst::ICMP_UGT, Addr, UpperLimit));
+ }
----------------
aqjune wrote:
> Is this case covered as well?
> ```
> a = alloca i32 // 4 bytes
> p1 = gep a, -1
> p2 = gep inbounds p1, 2
> ```
> p2 is poison because p1 is not in-bounds pointer.
> UpperCheck will succeed because Addr is smaller than a + 4.
Hadn't been handled in the original patch, see forthcoming refresh.
================
Comment at: lib/Transforms/Instrumentation/PoisonChecking.cpp:280
+ break;
+ }
};
----------------
jdoerfert wrote:
> aqjune wrote:
> > A silly question: where is the poison-ness of operands of GEP checked at?
> I think this is relates to your other question: nowhere yet (I think)
>
> Though, this is a really good point. The check for an inbound gep could include one to ensure a valid base pointer. How to do that is tricky though. If the base allocation is known, one can substract the base pointer from the base allocation and do `diff >= 0 && diff <= length`. If the base allocation is not known, we would need to track more information throughout the program. There are different ways to do this but I guess the first case should be covered next.
I think nlopes question was actually about one of the operands being directly poison. Which is handled via the propagatesFullPoison code.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D64451/new/
https://reviews.llvm.org/D64451
More information about the llvm-commits
mailing list