[llvm-commits] [llvm-gcc-4.2] r55650 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

[Dale Johannesen]

On Sep 21, 2008, at 12:17 PMPDT, Chris Lattner wrote:

> On Sep 2, 2008, at 2:18 PM, Dale Johannesen wrote:
>> URL: http://llvm.org/viewvc/llvm-project?rev=55650&view=rev
>> Log:
>> Don't convert atomics that aren't supported by the target.
>> This gets us undefined functions at linktime instead of
>> crashes in llvm, which is what gcc does.
>
> Hi Dale,
>
>> +++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Tue Sep  2 16:18:19 2008
>> @@ -4590,82 +4590,113 @@
>>    return true;
>>  }
>>  case BUILT_IN_BOOL_COMPARE_AND_SWAP_8: {
>> +#if defined(TARGET_POWERPC)
>> +    if (!TARGET_64BIT)
>> +      return false;
>> +#endif
>>    Result = BuildCmpAndSwapAtomicBuiltin(exp,
>> long_long_unsigned_type_node,
>>                                          true);
>
> llvm-convert.cpp is target independent code.

No, it's not; there's lots of #ifdef TARGET_LLVM's in here.  (If  
you're saying it's not target-dependent because it's using some  
abstraction rather than TARGET_POWERPC, I strongly disagree.)

> Checking for
> TARGET_POWERPC here is not right.

That may be, but I didn't introduce the target dependency; this whole
block is wrapped in
#if defined(TARGET_ALPHA) || defined(TARGET_386) ||  
defined(TARGET_POWERPC)

> Why not just check TARGET_64BIT or
> something like that?  Does this happen on x86-32 as well?  If not,
> maybe there some be some new LLVM_BUILTIN_ATOMIC_OK(...) macro, which
> PPC defines.


Implementing 64-bit atomic intrinsics on ppc32 makes no sense, because  
there is no hardware 64-bit atomic operation; these cannot work.  In  
contrast, there is a 64-bit atomic operation on x86-32, although I  
haven't hooked it up yet.