Removing TargetMachine CPU auto-detection for PowerPC and SystemZ?

Hi Hal,

I only just noticed that about a year ago, Jim removed CPU auto-detection
for the X86 target:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/071991.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140407/212676.html

Currently the X86 backend does CPU auto-detection and subtarget feature
detection when the TargetMachine is created if no explicit CPU was
specified. It's counterintuitive for low level tools like ‘llc’ to do
this, as it means the same .ll file compiled on heterogenous machines
generates different results from the same ‘llc’ command line. It is still
useful to be able to opt-in to such behavior to, for example, replicate
clang’s behavior when -mcpu=native is supplied to clang. My thought is
to do something similar here and teach ‘llc’ to recognize -mcpu=native
and probe the host CPU if that is given. The subtarget features will
then be filled in according to the feature string for that CPU. This
(a) changes the auto-detection from opt-out to opt-in and (b) moves
the logic out of the core target backend and into the tools drivers.

Attached are draft patches that do this for X86. Similar but smaller
cleanups can also be done for SystemZ and PowerPC if it’s agreed this
is a good idea.

However, this was then never implemented for SystemZ and PowerPC. Should
we do so as well?

Note that mesa has in the meantime changed to do the auto-detection before
setting up the JIT context, and I assume other JIT users have done so as
well by now. For clang, this was never done automatically anyway.

Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
To: "Hal J. Finkel" <hfinkel@anl.gov>
Cc: llvmdev@cs.uiuc.edu, grosbach@apple.com
Sent: Monday, March 23, 2015 12:21:17 PM
Subject: Removing TargetMachine CPU auto-detection for PowerPC and SystemZ?

Hi Hal,

I only just noticed that about a year ago, Jim removed CPU
auto-detection
for the X86 target:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/071991.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140407/212676.html

>Currently the X86 backend does CPU auto-detection and subtarget
>feature
>detection when the TargetMachine is created if no explicit CPU was
>specified. It's counterintuitive for low level tools like ‘llc’ to
>do
>this, as it means the same .ll file compiled on heterogenous
>machines
>generates different results from the same ‘llc’ command line. It is
>still
>useful to be able to opt-in to such behavior to, for example,
>replicate
>clang’s behavior when -mcpu=native is supplied to clang. My thought
>is
>to do something similar here and teach ‘llc’ to recognize
>-mcpu=native
>and probe the host CPU if that is given. The subtarget features will
>then be filled in according to the feature string for that CPU. This
>(a) changes the auto-detection from opt-out to opt-in and (b) moves
>the logic out of the core target backend and into the tools drivers.

>Attached are draft patches that do this for X86. Similar but smaller
>cleanups can also be done for SystemZ and PowerPC if it’s agreed
>this
>is a good idea.

However, this was then never implemented for SystemZ and PowerPC.
Should
we do so as well?

Yes, I think we should.

-Hal

Checked in for SystemZ as r233540. Do you want me to do PowerPC too?

Bye,
Ulrich

From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: grosbach@apple.com, llvmdev@cs.uiuc.edu
Sent: Monday, March 30, 2015 1:41:31 PM
Subject: Re: Removing TargetMachine CPU auto-detection for PowerPC and SystemZ?

> > >Attached are draft patches that do this for X86. Similar but
> > >smaller
> > >cleanups can also be done for SystemZ and PowerPC if it’s agreed
> > >this is a good idea.
> >
> > However, this was then never implemented for SystemZ and PowerPC.
> > Should we do so as well?
>
> Yes, I think we should.

Checked in for SystemZ as r233540. Do you want me to do PowerPC too?

Fine by me.

Thanks again,
Hal

Checked in for PowerPC as 233684.

Thanks,
Ulrich