[llvm-commits] [PATCH] New pass: pointer (bounds) tracking!

Török Edwin edwintorok at gmail.com
Thu Jul 2 12:32:33 PDT 2009


Hi,

The attached patch introduces a new pass that can be queried for
allocation size  of pointers,
and contains a simple solver [*] for (a ult b) inequalities useful in
bounds checking. This is based on the bounds checker tool I developed
for my undergraduate thesis.

If this pass is something that would be accepted in LLVM, I will cleanup
the code to conform to LLVM coding style, add testcases, and resubmit
the patch. I have just attached the patch now as a preview.

I've seen that there is a lot of work being done to support SSI/ABCD. I
think my approach is complementary: I try to determine whether the
existing bounds checks are sufficient for the safety of a memory access,
and not whether any of the bounds checks are redundant and can be removed.

I haven't made up  by mind whether all this should be in one pass, or I
should split it up further:
PointerTracking for size information and bounds checking, and SCEVSolver
for the SCEV inequality solver?
Or maybe the SCEVSolver parts should be integrated directly into
ScalarEvolution?

[*]
The solver uses isLoopGuardedByCond(), but is able to handle more
complicated situations by using
properties of SCEV expressions, and transitivity of ULT/ULE:
 - if a SCEVAddRecExpr is monotonic it checks whether the start and exit
value is known to be ULT Limit.
 - for PHI nodes that are SCEVUnknowns it checks whether all parts of
the PHI are known to be ULT
 - if a value is a constant offset away from a PHI: C + X <u B -> X <u B-C
It also looks for predicates among the basic blocks that dominate the
memory access, trying to
find a predicate that is sufficient for the validity of the memory access.

Best regards,
--Edwin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pointertracking.patch
Type: text/x-diff
Size: 18722 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090702/4e96c0e7/attachment.patch>


More information about the llvm-commits mailing list