This is an archive of the discontinued LLVM Phabricator instance.

CodeGen: Don't completely mess-up optimized atomic libcalls
ClosedPublic

Authored by majnemer on Aug 28 2014, 5:41 AM.

Details

Summary

We did a great job getting this wrong:

  • We messed up which LLVM IR types to use for arguments and return values. The optimized libcalls use integer types for values.

    Clang attempted to use the IR type which corresponds to the value passed in instead of using an appropriately sized integer type. This would result in violations of the ABI for, as an example, floating point types.
  • We didn't bother recording the result of the atomic libcall in the destination memory.

This fixes PR20780.

Diff Detail

Repository
rL LLVM

Event Timeline

majnemer updated this revision to Diff 13029.Aug 28 2014, 5:41 AM
majnemer retitled this revision from to CodeGen: Don't completely mess-up optimized atomic libcalls.
majnemer updated this object.
majnemer added a reviewer: rsmith.
majnemer added a subscriber: Unknown Object (MLST).
rsmith accepted this revision.Aug 28 2014, 6:32 PM
rsmith edited edge metadata.

Seems legit.

lib/CodeGen/CGAtomic.cpp
474–476 ↗(On Diff #13029)

Use ASTContext::toBits instead of 8 here?

This revision is now accepted and ready to land.Aug 28 2014, 6:32 PM

Hmm, please also add some more tests covering the by-value argument of non-integer type case.

majnemer closed this revision.Aug 29 2014, 12:37 AM
majnemer updated this revision to Diff 13069.

Closed by commit rL216714 (authored by @majnemer).

robertlytton added inline comments.
cfe/trunk/lib/CodeGen/CGAtomic.cpp
747

Hi David,

I've been chasing issues with libcxx for the xcore - hence finding this late in the day.

For non-optimized lib calls that return a value, don't we want to return the 'Res'?
viz:
if (!RetTy->isVoidType()) {

if (HaveRetTy)
  return Res;
if (UseOptimizedLibcall) {
  ...

Have I understood the code correctly?

Robert

majnemer added inline comments.Nov 25 2014, 12:11 PM
cfe/trunk/lib/CodeGen/CGAtomic.cpp
747

This bug manifests itself in exactly one case as far as I can tell: __atomic_compare_exchange. I'm working on a small cleanup to this code because it's not in great shape. It'll be fixed by tonight.

... it was __atomic_compare_exchange of a structure that was failing.
Thank you.

... it was __atomic_compare_exchange of a structure that was failing.
Thank you.

Should be fixed in rL222798.