[cfe-dev] CodeGen issue with atomic_load_n

[David Majnemer]

This should be fixed in r224110.

On Wed, Dec 10, 2014 at 5:34 AM, Beren Minor <beren.minor at gmail.com> wrote:
>
> Hello!
>
> Here is a patch for this bug, as it is still unresolved and the behavior
> can still be reproduced in trunk.
>
> It looks like it is simply an issue with the return type deduction of
> __atomic_* builtins. They are not using an unqualified version of the value
> type, whereas the __sync_* builtins are.
>
> Regards,
> --
> Beren Minor
>
> On Wed, Nov 20, 2013 at 12:07 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> I think that's this bug here:
>> http://llvm.org/bugs/show_bug.cgi?id=17306
>>
>> Probably it's a bug in Clang's builtin IR generation.
>>
>>
>> On Tue, Nov 19, 2013 at 3:11 AM, Beren Minor <beren.minor at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I found some strange codegen output when playing with Clang's
>>> implementation of GCC atomic builtins and would like to know if this is
>>> some expected behavior or known issue.
>>>
>>> The test case is very simple, and the disassembly can be seen here:
>>> http://bit.ly/18LED7t
>>>
>>> It looks to me that these instructions after the load are unnecessary,
>>> and GCC does not generate them:
>>>     movl    %eax, -4(%rsp)
>>>     movl    -4(%rsp), %eax
>>>
>>> After investigating, it appears that this is caused by the volatile
>>> qualifier of the pointer parameter. Without it, the generated code is the
>>> same as GCC.
>>>
>>> It looks like the volatile qualifier is propagated to some temporary
>>> variable that Clang uses in the LLVM IR, and after storing the atomic load
>>> result in this temporary, it has to reload it again before returning it.
>>> Showing the IR with -emit-llvm exhibits clearly this issue.
>>>
>>> It seems to me that is is unnecessary to make this temporary volatile,
>>> isn't it?
>>> --
>>> Beren Minor
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141212/ffb2c7de/attachment.html>