CodeGen issue with atomic_load_n

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

CodeGen issue with atomic_load_n

Beren Minor
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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] CodeGen issue with atomic_load_n

Reid Kleckner-2
I think that's this bug here:

Probably it's a bug in Clang's builtin IR generation.


On Tue, Nov 19, 2013 at 3:11 AM, Beren Minor <[hidden email]> 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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev