How do I specify a specific PowerPC CPU to clang?

Clang Frontend
1

I want to have clang and then llvm generate code for a specific CPU. Eg, suppose I want it to build for the PowerPC 750 CPU, how am I meant to tell clang

I’m running the latest latest trunk versions of clang and llvm on windows and I’m running clang in the debugger. I’ve tried all sorts of combinations, but can’t get the “CPU” member of TargetOptions to be populated. e.g. here are some arguments I’ve tried that didn’t work: -target ppc750-bla-darwin -S c:\projects\llvm_750\test1.cpp -o -

Thanks,

Sean

2

I want to have clang and then llvm generate code for a specific CPU. Eg, suppose I want it to build for the PowerPC 750 CPU, how am I meant to tell clang

I’m running the latest latest trunk versions of clang and llvm on windows and I’m running clang in the debugger. I’ve tried all sorts of combinations, but can’t get the “CPU” member of TargetOptions to be populated. e.g. here are some arguments I’ve tried that didn’t work: -target ppc750-bla-darwin -S c:\projects\llvm_750\test1.cpp -o -

Thanks,

Sean

Hi Sean,

Interesting you should ask this question. Today I added an -mcpu option to my version off clang/LLVM:

[~/ellcc] main% bin/ecc -target ppc-ellcc-linux hello.c -v -mcpu=750

clang version 3.2 (svn - Revision 7636: /ellcc/branches/newlib/llvm/tools/clang 2979)

Target: ppc-ellcc-linux

Thread model: posix

“/home/rich/ellcc/bin/ecc” -cc1 -triple ppc-ellcc-linux -S -disable-free -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -mconstructor-aliases -msoft-float -target-cpu 750 -target-linker-version 2.21.53.0.1 -momit-leaf-frame-pointer -v -resource-dir /home/rich/ellcc/bin/…/libecc -fmodule-cache-path /var/tmp/clang-module-cache -fno-dwarf-directory-asm -fdebug-compilation-dir /home/rich/ellcc -ferror-limit 19 -fmessage-length 87 -mstackrealign -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/hello-KzHR2J.s -x c hello.c

clang -cc1 version 3.2 based upon LLVM 3.2svn default target x86_64-unknown-linux-gnu

#include “…” search starts here:

#include <…> search starts here:

/home/rich/ellcc/bin/…/libecc/include

/home/rich/ellcc/bin/…/libecc/usrinclude/ppc/linux

/home/rich/ellcc/bin/…/libecc/usrinclude/ppc

/home/rich/ellcc/bin/…/libecc/usrinclude/linux

/home/rich/ellcc/bin/…/libecc/usrinclude

End of search list.

“/home/rich/ellcc/bin/ppc-elf-as” -o /tmp/hello-ZIWKej.o /tmp/hello-KzHR2J.s -a32

“/home/rich/ellcc/bin/ecc-ld” -m elf32ppc --build-id --hash-style=gnu -e _start --eh-frame-hdr -Bdynamic -dynamic-linker /usr/libexec/ld.so -o a.out /home/rich/ellcc/bin/…/libecc/lib/ppc/linux/crt0.o /home/rich/ellcc/bin/…/libecc/lib/ppc/linux/crtbegin.o -nostdlib -L/home/rich/ellcc/bin/…/libecc/ldscripts/linux -L/home/rich/ellcc/bin/…/libecc/lib/ppc/linux -L/home/rich/ellcc/bin/…/libecc/lib/ppc /tmp/hello-ZIWKej.o -Telf32ppc.x -lc -lcompiler-rt /home/rich/ellcc/bin/…/libecc/lib/ppc/linux/crtend.o

[~/ellcc] main%

Currently the TOT doesn’t support -mcpu for the PowerPC.

-Rich

3

Sean, Richard,

I added -mcpu support for PPC to trunk clang in r158334. Does this not
work for you?

-Hal

4

Hal,

That figures. I'm currently running r158294. I'll update.

-Rich

5

Hal,

Thanks for adding this feature.

Please can I offer an improvement to it? In your commit comments you stated "a few preprocessor defines for common CPU types have been added". Attached is a patch that adds more. I have tried to match the defines that gcc generates and the IBM compiler documentation, where the two agree and where I have been able to confirm by testing. FWIW, I am porting code that requires the _ARCH_PPCGR and _ARCH_PWRx defines to compile correctly, hence my motive!

In addition to the defines you added, I have added ones for 60x and 74xx series, additionally defining _ARCH_PPCGR where applicable. I also fleshed out the 970, pwr6 and pwr7 sets to include _ARCH_PWR{4-6}, _ARCH_PPCGR and _ARCH_PPCSQ as applicable (which are additionally defined by gcc for these architectures).

Cheers
Andy

ppc-defines.patch (8.54 KB)

6

> Sean, Richard,
>
> I added -mcpu support for PPC to trunk clang in r158334. Does this
> not work for you?
>
> -Hal

Hal,

Thanks for adding this feature.

Andy,

Please can I offer an improvement to it?

Of course :slight_smile:

In your commit comments you
stated "a few preprocessor defines for common CPU types have been
added". Attached is a patch that adds more.

A few quick things:

+ /// \brief Flags for architecture specific defines.
+ typedef enum {
+ ppc_arch_none = 0,
+ ppc_arch_name = 1 << 0, // <name> is substituted for arch name.
+ ppc_arch_ppcgr = 1 << 1,

You need to follow the coding conventions for naming the constants here:
http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly

+ ppc_arch_t defs = (ppc_arch_t)llvm::StringSwitch<int>(CPU)
+ .Case("440", ppc_arch_name)
+ .Case("450", ppc_arch_name | ppc_arch_440)
+ .Case("601", ppc_arch_name)

The indentation of the .Case seems odd here. I think just one
indentation level is fine.

Otherwise, I think this looks good. Thanks!

Please send an updated patch and I'll commit.

-Hal

7

Ooops, sorry, I've spent the morning working to another set of coding standards and its unfortunately carried across!

Attached is a fixed patch.

Cheers
Andy

ppc-defines.patch (8.54 KB)

8

>
>> > Sean, Richard,
>> >
>> > I added -mcpu support for PPC to trunk clang in r158334. Does
>> > this not work for you?
>> >
>> > -Hal
>>
>> Hal,
>>
>> Thanks for adding this feature.
>>
>
> Andy,
>
>> Please can I offer an improvement to it?
>
> Of course :slight_smile:
>
>> In your commit comments you
>> stated "a few preprocessor defines for common CPU types have been
>> added". Attached is a patch that adds more.
>
> A few quick things:
>
>> + /// \brief Flags for architecture specific defines.
>> + typedef enum {
>> + ppc_arch_none = 0,
>> + ppc_arch_name = 1 << 0, // <name> is substituted for arch
>> name.
>> + ppc_arch_ppcgr = 1 << 1,
>
> You need to follow the coding conventions for naming the constants
> here:
> LLVM Coding Standards — LLVM 18.0.0git documentation

Ooops, sorry, I've spent the morning working to another set of coding
standards and its unfortunately carried across!

Attached is a fixed patch.

r159665. Thanks!

-Hal