[llvm-commits] [llvm] r141333 - in /llvm/trunk: include/llvm/Intrinsics.td lib/Analysis/BasicAliasAnalysis.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h lib/Target/CBackend/CBackend.cpp lib/Tr

[Eli Friedman]

On Fri, Oct 7, 2011 at 12:34 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Eli,
>
>> --- llvm/trunk/lib/VMCore/AutoUpgrade.cpp (original)
>> +++ llvm/trunk/lib/VMCore/AutoUpgrade.cpp Thu Oct  6 18:20:49 2011
>> @@ -206,6 +223,80 @@
>>
>>         // Remove intrinsic.
>>         CI->eraseFromParent();
>> +    } else if (F->getName().startswith("llvm.atomic.cmp.swap")) {
>> +      IRBuilder<>  Builder(C);
>> +      Builder.SetInsertPoint(CI->getParent(), CI);
>> +      Value *Val = Builder.CreateAtomicCmpXchg(CI->getArgOperand(0),
>> +                                               CI->getArgOperand(1),
>> +                                               CI->getArgOperand(2),
>> +                                               Monotonic);
>
> in your llvm-gcc patch llvm.atomic.cmp.swap was replaced with
> CreateAtomicCmpXchg with SequentiallyConsistent, but here you replace with
> Monotonic.  Why the difference?  Is it because the gcc builtins have an
> implicit memory barrier?

Yes, they have a memory barrier, and the old atomic intrinsics did
not; llvm-gcc used to put llvm.memory.barrier's around every atomic
operation.  You might have noticed that in my llvm-gcc patch, I
removed the calls to llvm.memory.barrier from the gcc builtins, and
didn't replace them with anything.

Autoupgrading old llvm-gcc/clang code actually does lead to slightly
different IR, because we upgrade each call individually: instead of a
"cmpxchg seq_cst", we end up with "fence seq_cst+cmpxchg
monotonic+fence seq_cst".  Strictly speaking, that isn't semantically
equivalent, but we end up with equivalent code generation in practice.

-Eli