[LLVMdev] Proposal: Move host CPU auto-detection out of the TargetMachine

Erik Schnetter
Fri, 11 Apr 2014 01:47:01 -0000

On Apr 10, 2014, at 21:32 , Jim Grosbach <grosbach at apple.com> wrote:

> We already decide on a default. For these three targets is “whatever the
user is running on.” For all the other targets it’s something the backend
selects. I’m proposing we, as you say, remove the uncertainty and have the
default always be the same from one run to the next even (especially) when those
runs are on different machines.
>
> For X86, there’s two options, the “generic” target that backend already
supports or “core2” which is what clang typically defaults to for x86_64h. I
lean towards the former for simplicity. We also don’t have to change all three
of the ports. I’m personally motivated primarily by x86, and was intending to
leave it to the maintainers of the other two targets to decide what they want to
do here, perhaps with some strong encouragement.
>
> It’s very important that a run of “llc” on one machine produce the same
output on two heterogenous machines given the same input and command lines*.
That’s not true right now, leading to lots of bot failures that patch
originators can’t reproduce because they’re getting different code locally due
to the auto-detection. The recent “Test failures with 3.4.1” thread for
examples.

As one of the contributors to pocl <http://pocl.sourceforge.net/>, I want
to emphatically chime in here. Before our 0.9 release, we had to discover that
running clang, llc, opt, etc. often give results that differ depending on which
machine they are run, and also between each other. We ended up specifying
exactly what kind of machine is to be targeted, via various -triple, -march, and
-mcpu options.

The fact that these options have a different syntax for different LLVM tools
didn't help...

Any step towards more unification among different machines and different
LLVM-based tools would be a great help.

-erik

> -Jim
>
> * With the caveat of platform differences like elf vs. macho. A similar
argument can be made there, but unlike CPU, there’s no sensible way to define a
least-common-denominator default, so it’s harder. I’m explicitly avoiding
opening that can of worms.
>
> On Apr 9, 2014, at 10:19 PM, Eric Christopher <echristo at gmail.com>
wrote:
>
>> I'm not a huge fan of this because then you get to decide on a
default
>> for all the ports, but I can understand if people want to move this
>> way to reduce uncertainty.
>>
>> Alternately have a way for the backend to pretty print out the results
>> of the auto-detection when asked?
>>
>> *shrug*
>>
>> -eric
>>
>> On Tue, Apr 8, 2014 at 1:59 AM, Jim Grosbach <grosbach at
apple.com> wrote:
>>> All,
>>>
>>> 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.
>>>
>>> -Jim
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

--
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140410/063d9ec9/attachment.sig>