[llvm] r187248 - [PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc.

[Bill Schmidt]

On Fri, 2013-07-26 at 15:12 -0700, Chandler Carruth wrote:
> 
> On Fri, Jul 26, 2013 at 2:39 PM, Bill Schmidt
> <wschmidt at linux.vnet.ibm.com> wrote:
>         Both GCC and LLVM will implicitly define __ppc__ and
>         __powerpc__ for
>         all PowerPC targets, whether 32- or 64-bit.  They will both
>         implicitly
>         define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets,
>         and not
>         for 32-bit targets.
> 
> 
> I don't think this is true for all versions of GCC we use, and
> certainly isn't true for all versions of Clang (see my commit some
> time ago fixing a Clang bug here). 

So, precisely what was wrong with the previous versions?

My motivation for looking at this was this code in
lib/Target/PowerPC/PPCJITInfo.cpp:

#if (!defined(__ppc__) && !defined(__powerpc__)) ||
defined(__powerpc64__) || defined(__ppc64__)

This is supposed to be guarding against anything but a 32-bit target.
But checking __ppc__ and __powerpc__ should be irrelevant for that,
since these should be defined for all PowerPC targets, 32- and 64-bit.
The code isn't wrong, but it's unnecessary to do more than:

#if defined(__ppc64) || defined(__powerpc64__)

Surely that change is safe for all existing compilers...right?

I'm happy to forget about the rest of this, but this change ought to
happen if there's no reason to avoid it.


>  
>          We cannot be sure that all other possible
>         compilers used to compile Clang/LLVM define both __ppc__ and
>         __powerpc__, for example, so it is best to check for both when
>         relying
>         on either inside the Clang/LLVM code base.
> 
> Actually, we can be sure that they don't. ;] GCC, Clang, and xlC are
> (afaik) the only ppc targeting toolchains we need to support. That
> said, we need to support many versions of them.

I'll take your word for there being versions of these that are broken.
I'm not aware of GCC versions that are broken in this manner, but I try
not to use ancient GCCs, so who knows. ;)

Thanks,
Bill