[PATCH] An Aliasing Validator/Sanitizer

Andrew Trick atrick at apple.com
Sat Aug 23 15:53:46 PDT 2014


Hal,

I think both these validation modes will be extremely useful. The first (restrict validation) tests the user annotations. The second (AA validation) tests our AA implementation.

For AA validation we want to be able to recompile a potentially broken program with exactly the same optimization and inlining, at least up to the point where we insert instrumentation.

Your design looks good to me. It can be extended to validate AA across any codegen (or ISEL) pass, as long as memory operands are intact. Validating AA decisions from earlier passes, before the IR is frozen would require a different approach. (If the pass modifies IR while recording decisions we have a problem). To deal with that (in the future) we could use an instruction numbering analysis to identify pairs.

I don't have any conerns at the moment about your design or implementation.

http://reviews.llvm.org/D4446






More information about the llvm-commits mailing list