llvm dev - Oct 2017 - SSE instructions and alignment of the return value of 'new'

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.

Thanks in advance.

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

Does the crash happen if you compile with -fnew-alignment=8? That's
supposed to change what clang assumes the alignment of memory allocated
with new will be.

~Craig

On Mon, Oct 2, 2017 at 3:11 PM, Riyaz Puthiyapurayil via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
>
>
> Thanks in advance.
>
>
>
> /Riyaz
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/9dca58d6/attachment.html>

I think as you alluded to, movaps xmm, m128 requires m128 to be 16 byte
aligned to load 4 single precision fp into xmm.
Glibc had a bug open for not supporting variable alignment on malloc/new as
standard mandates it, but they decided not to fix according to this bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
The issue is 'resolved wontfix' but I'm not exactly sure what they
decided
to do -- it seems they tried to put in workaround in gcc as glibc won't
budge. If workaround is in gcc, clang for sure would also need that.

-Kevin

On Mon, Oct 2, 2017 at 6:44 PM, Craig Topper via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Does the crash happen if you compile with -fnew-alignment=8? That's
> supposed to change what clang assumes the alignment of memory allocated
> with new will be.
>
> ~Craig
>
> On Mon, Oct 2, 2017 at 3:11 PM, Riyaz Puthiyapurayil via llvm-dev <
> llvm-dev at lists.llvm.org> 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.
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> /Riyaz
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/52451a0f/attachment.html>

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>

-fnew-alignment=8 makes the crash go away. Can you point me to the documentation
for this option? I couldn’t find it.

/ Riyaz

On Oct 2, 2017, at 3:44 PM, Craig Topper <craig.topper at
gmail.com<mailto:craig.topper at gmail.com>> wrote:

Does the crash happen if you compile with -fnew-alignment=8? That's supposed
to change what clang assumes the alignment of memory allocated with new will be.

~Craig

On Mon, Oct 2, 2017 at 3:11 PM, Riyaz Puthiyapurayil via llvm-dev <llvm-dev
at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> 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.

Thanks in advance.

/Riyaz

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=mMZWMrEZcvPMLSsEQSah9FOTwza1UudSDkAneN47U9lD3qu6gt3kpnIb4MWV77cM&m=q9SGsai0JEZwsIwupiWLBnPcZSxAkYIMkrR1rNw2RC4&s=1BMveWM9s7snji5Imqqfm8DIHH1A6VqWju-HyakRIg0&e=>


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

We started optimizing global operator new more aggressively in
https://reviews.llvm.org/rL283789<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_rL283789&d=DwMD-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=mMZWMrEZcvPMLSsEQSah9FOTwza1UudSDkAneN47U9lD3qu6gt3kpnIb4MWV77cM&m=cHbBPBY4qGyBNMbyY3uMJXZekzh2GTh3ovvIDDiH8c0&s=1qQqNKtEdbgif1Q3mdj4f19fswy__wtXqySnSz6CnJ0&e=>.

Thank you. It is good that it is being more aggressive. However, I plan to use
-fnew-alignment=8 until we can configure our memory allocator to align based on
the size (this is a more disruptive change which will take some time to
stabilize).

--
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/20171003/94887336/attachment.html>