[LLVMdev] load widening conflicts with AddressSanitizer
criswell at illinois.edu
Fri Dec 16 14:45:01 PST 2011
On 12/16/11 4:35 PM, Chris Lattner wrote:
> On Dec 16, 2011, at 2:27 PM, Kostya Serebryany wrote:
>> This is a good question. Would it be possible for ASan to do its
>> instrumentation earlier?
>> It would be possible but undesirable.
>> First, asan blows up the IR and running asan early will increase the
>> Second, asan greatly benefits from all optimizations running before
>> it because it needs to instrument less memory accesses.
>> It actually benefits from load widening too: in the test case above
>> asan instruments only one load instead of two.
> You certainly wouldn't want to run asan before mem2reg/SRoA, but after
> that, the benefits are probably small. I'd guess that there is some
> non-zero value to exposing the code generated by asan to the
> optimizer. Have you looked at that at all?
>> In this case, we have an array of 22 bytes which is 16-aligned.
>> I suspect that load widening changed the alignment of alloca
>> instruction to make the transformation legal. Right?
>> Can we change the load widening algorithm to also change the size of
>> alloca instruction to be dividable by 16?
>> This will solve the problem, at least the variant I observe now.
> I believe it is 16-byte aligned based on ABI requirements for x86-64,
> though you're right that the optimizer will increase alignment in
> other cases. In any case, we don't want to increase the size of the
> object, because that would prevent packing some other data in after
> it. For example, a 2-byte aligned 10 byte object can be placed after
> it in memory if we keep it 22-bytes in size.
It seems that another option would be to check that both the alignment
*and* size of the memory object permit safe load-widening and to not
perform it on memory objects such as this 22-byte object.
Do you think such unsafe cases occur often in practice?
-- John T.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev