Driver: Default CPUs

I think I hate the arm notion of “cpu” in the output file. Only arch and tune should
matter :wink:

MIPS and (IIRC) powerpc don’t work this way. For MIPS -march is the minimum
ISA you’re compiling for and if it’s a specific processor then by default will
tune for that unless you want something else. There’s no real idea of a “generic”
cpu for tuning or scheduling itinerary, you’d usually tune for whatever processor
is the most important.

So it looks like this decision is mostly ARM related. For ease of compatibility
I’d suggest doing whatever gcc does, but I don’t really think it matters that
much.

IMO you should specify the minimum cpu you want to run on via
-march and the one you want to tune for via -mtune (not that we really support
doing this in the llvm backend anyhow) and that -mcpu should basically
die in a fire. Historically though the cpu is automagically set from the architecture
targeted and I think we should continue that and use default tuning to
some processor of that sort.

-eric

Hi Eric,

IMO you should specify the minimum cpu you want to run on via

-march and the one you want to tune for via -mtune (not that we really support

doing this in the llvm backend anyhow) and that -mcpu should basically

die in a fire. Historically though the cpu is automagically set from the architecture

targeted and I think we should continue that and use default tuning to

some processor of that sort.

OK, I give in, I’ll find a way of getting the defaults generated from ARM.td (perhaps by #including ARMGenSubtarget.inc?) instead of deleting it outright.

I may delay this though until after the conference in case people have different ideas about the direction of the driver.

Cheers,

James

OK, I give in, I’ll find a way of getting the defaults generated from ARM.td (perhaps by #including ARMGenSubtarget.inc?) instead of deleting it outright.

Well, if you want to move to a system where it’s only arch and tune that’s great with me, it might mean some incompatibility with gcc and assorted questions though.

I may delay this though until after the conference in case people have different ideas about the direction of the driver.

nod That seems reasonable.

-eric

OK, I give in, I’ll find a way of getting the defaults generated from ARM.td (perhaps by #including ARMGenSubtarget.inc?) instead of deleting it outright.

Well, if you want to move to a system where it’s only arch and tune that’s great with me, it might mean some incompatibility with gcc and assorted questions though.

Warn about -mcpu being deprecated and set -mtune to the value passed to it. If -mtune is given, ignore -mcpu?

nod Pretty much.

-eric