[llvm-dev] SSE instructions and alignment of the return value of 'new'

[Friedman, Eli via llvm-dev]

On 10/2/2017 3:11 PM, Riyaz Puthiyapurayil via llvm-dev wrote:
>
> I have some programs crashing when I upgraded from clang 3.9.1 to 
> clang 4.0.1.
>
> Debugging this I found the reason for the crash. This is happening in 
> the following assembly fragment for a piece of code allocating a class 
> object (size: 24 bytes) using operator new and then initializing it:
>
> 0x00002aaaafc145f3 <+35>:    callq  0x2aaaafdf5f90 <operator 
> new(unsigned long)>
>
> 0x00002aaaafc145f8 <+40>:    mov    %rax,%r13
>
> 0x00002aaaafc145fb <+43>:    xorps  %xmm0,%xmm0
>
> => 0x00002aaaafc145fe <+46>: movaps %xmm0,0x0(%r13)
>
> The value in %r13 (from the return value of operator new) is not 
> appropriately aligned causing the crash. The memory allocation is done 
> by a custom memory allocator that is returning 8-byte aligned blocks. 
> The memory allocator has not changed between the two versions of the 
> program (the one using clang 3.9.1 versus the one using clang 4.0.1). 
> The version of libstdc++ is also the same. The command line options to 
> clang are unchanged (-msse2 is specified in both cases). But I found 
> that clang 3.9.1 is not generating SSE instructions but clang 4.0.1 is 
> generating them in the above case.
>
> The fix in our code is to make an API call to configure the custom 
> allocator to always return appropriately aligned memory. But I would 
> like to know if there is a known change in LLVM or clang to assume 
> that malloc will return > 8 byte aligned memory based on the 
> allocation size  or if this has always been the case. I want to know 
> if my program compiled with 3.9.1 also has a problem that was just not 
> exposed in testing.
>

We started optimizing global operator new more aggressively in 
https://reviews.llvm.org/rL283789.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

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