[cfe-dev] Driver: Default CPUs

[James Molloy]

Hi Russ,

> Part of the problem here is that some of the RPM based Linux
> porting folks are 'coining' their own tuple definitions to fit
> 'political' branding decisions as to hardware FP and such.  I
> don't see HOW one avoids 'nasty' when one has to interface to
> that layer of the stack

I'm not sure I fully understand the problem here. Could you provide a concrete set of examples?

> But for the reasons above, this shifts the load of chasing
> political decisions to the wrong place ... it is all fine, and
> well and good for people to make what are essentially
> 'branding' decisions in their tuple, but it should not
> transfer the load for supporting such (sorry, but my feeling:)
> insanity into code

Parsing toolchain and OS-specifics out of the host environment and triple should be the job of the driver, I agree (although remember that LLVM itself has a Triple type that deals with some of this stuff).

But again, I'm not certain where this relates to the default CPUs. Perhaps an example will make it clearer?

> But 'blended' just disguises the issue of whose ox is
> being gored by abstracting it behind another level of hiding
> ... The argument could be made that 'blended' should be that
> capable of running on the largest number of platforms (and
> thus at the expense of code bload carrying around run time
> maths code, not needed when HW FP _is_ present

I'm not aware of an architecture where default hardfp vs. Softfp is different between CPUs of the same subarchitecture. Therefore, specifying the subarchitecture (in ARM's case, 'v7' or 'v7m') should have enough information to set up a suitable default calling convention.

Also, the calling convention is often altered by the target triple. It's not related intrinsically to the target CPU, IMHO.

Cheers,

James

-----Original Message-----
From: R P Herrold [mailto:herrold at owlriver.com]
Sent: 12 October 2011 11:21
To: James Molloy
Cc: clang development ML
Subject: Driver: Default CPUs

On Wed, 12 Oct 2011, James Molloy wrote:

> The driver, currently, *always* sets the "-target-cpu" option to cc1. The
> way it finds a default CPU for an architecture is hardcoded and nasty, and
> I'd love to get rid of it.

Part of the problem here is that some of the RPM based Linux
porting folks are 'coining' their own tuple definitions to fit
'political' branding decisions as to hardware FP and such.  I
don't see HOW one avoids 'nasty' when one has to interface to
that layer of the stack

> My personal opinion is that there should be no need to set a default CPU all
> the time. The target triple should suffice,

But for the reasons above, this shifts the load of chasing
political decisions to the wrong place ... it is all fine, and
well and good for people to make what are essentially
'branding' decisions in their tuple, but it should not
transfer the load for supporting such (sorry, but my feeling:)
insanity into code

and if the user wants
> performance tuned to a specific CPU they should mention that on the
> commandline with -mcpu= or -mtune=. If no CPU is specified, I feel that a
> "blended" scheduling should be done such that the resultant code runs well
> on all chips with the given architecture/triple.

But 'blended' just disguises the issue of whose ox is
being gored by abstracting it behind another level of hiding
... The argument could be made that 'blended' should be that
capable of running on the largest number of platforms (and
thus at the expense of code bload carrying around run time
maths code, not needed when HW FP _is_ present

> What do people think? Do people care?

It is a discussion worth having, I think

- Russ herrold


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.