[LLVMdev] load widening conflicts with AddressSanitizer

[John Criswell]

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 
>> compile-time.
>> 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.

>
> -Chris
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111216/e6f74818/attachment.html>