[llvm-commits] [llvm] r160589 - in /llvm/trunk: include/llvm/Transforms/Utils/Local.h lib/Analysis/MemoryBuiltins.cpp test/Instrumentation/BoundsChecking/simple.ll

[Nuno Lopes]

Quoting Duncan Sands <baldrick at free.fr>:

> Hi Nuno,
>
>>>> baby steps toward fixing some problems with inbound GEPs that
>>>> overflow, as discussed 2 months ago or so.
>>>> Make sure we do not emit index computations with NSW flags so that
>>>> we dont get an undef value if the GEP overflows
>>>
>>> does this really help?  I mean, the optimizers may have exploited
>>> nsw, undef and
>>> inbounds before this point to produce really weird bitcode, and may
>>> exploit them
>>> afterwards, eg because after inlining they see that your computation
>>> is fed by
>>> undef.  I'm worried that this appears to fix something, but doesn't
>>> really.  I
>>> don't think this kind of issue can be fixed without some kind of compiler
>>> barrier like the llvm.identity intrinsic I mentioned a while ago.
>>
>> It surely helps.
>> When we reach this point, the GEP may be undef (or become undef
>> later), yes, but in that case the load/store was probably removed
>> already. Theoretically this may not be truth, but it happens in
>> practice.
>
> it depends on what guarantees your pass is providing.  If it is OK that it
> doesn't catch all out-of-bounds accesses, just most of them, then this patch
> is fine.  If that is not OK then this patch doesn't make any sense to me.

This pass doesn't use any structure on the side (like ASan and  
SAFEcode do), so it will never be able to catch all out-of-bounds  
accesses. It's a best effort, like FORTIFY_SOURCE.
Anyway, I understand the problem you described before, and it will be  
handled. But just not yet :)

Nuno