[cfe-dev] Driver: Default CPUs

[Eric Christopher]

On Oct 12, 2011, at 2:40 AM, James Molloy wrote:

> The arguments I've heard so far are:
>  *  Mine, that there should be no default CPU selected if the user doesn't
> select it himself. I feel it adds a hidden option that the user is unaware
> of, and depending on what that default is may cause inferior performance on
> the CPU the user actually runs it on.
>  * Jim's (? I forget who responded ?), that there *should* be a default CPU
> all the time, but perhaps some pseudo-CPUs could be added that exhibit a
> blended scheduling. For example for ARM, a "v7" pseudo-cpu could be added
> that has an itinerary that performs well on all v7 cores. By the way, I
> think ARM is the only high-visibility target with such a difference between
> cores that this matters. I assume MIPS and PowerPC are similar though?

> What do people think? Do people care?

I think I hate the arm notion of "cpu" in the output file. Only arch and tune should
matter ;)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111014/b9823aa7/attachment.html>