[llvm-commits] [PATCH] Re-introduce llvm::sys::getHostTriple() function.

[Kaylor, Andrew]

Hi Peter,

I see your point with regard to defaulting to something that we don't know will fail locally in cases where a triple isn't explicitly provided.  If everyone else finds your changes acceptable, I can go along with that.

I can test your patch on Windows if you can find a way to get it to be consistent.  I looked into something like that before and the best I could come up with was to disable the MCJIT tests in cases that I expected to have problems.  It seemed that in the build files the host triple and the target triple were specified using different naming schemes and I couldn't figure out a simple way to convert one to the other.  In your case, since you just want to always use the host triple (but possibly with the 32/64-bit conversion) it might be easier.

-Andy

-----Original Message-----
From: Peter Collingbourne [mailto:peter at pcc.me.uk] 
Sent: Friday, January 04, 2013 4:11 PM
To: Kaylor, Andrew
Cc: llvm-commits at cs.uiuc.edu; spop at codeaurora.org; joerg at NetBSD.org
Subject: Re: [llvm-commits] [PATCH] Re-introduce llvm::sys::getHostTriple() function.

On Fri, Jan 04, 2013 at 10:13:22PM +0000, Kaylor, Andrew wrote:
> >On Wed, Jan 02, 2013 at 02:10:57PM -0800, Andy Kaylor wrote:
> >>   I think the main issue with JIT/MCJIT and the target vs. host 
> >>triple is with the cross-building buildbots.  There probably are no 
> >>real world cases where the target triple won't be what the user 
> >>wants (user error aside), but a couple of the buildbots have problems with incompatible host and target.  Ideally, those buildbots should be configured to not enable JIT, but right now I believe a couple of them aren't.
> >
> > Peter Collingbourne responded:
> >I already mentioned such a real-world case -- the 32-on-64 bit build.
> >I think it's sensible to keep JIT on when configured for cross compiling by default to verify that the JIT continues to work in this configuration.
> 
> I'm not sure we're understanding one another here.  What I meant was that if the user intends to use JIT, he shouldn't have the build configured for incompatible cross-compilation.  That is, I'm not aware of a case where a user will want to compile for a target other than the current host *and* want to use the JIT.  It may be that I just don't understand the 32-on-64 bit use case you are referring to.

The purpose of the default target triple is to provide a default target when using LLVM as a traditional compiler.  It should not act as a default triple for local JIT, which is a separate use case in that it requires that the triple have some relationship with the triple for which the current process was compiled.

I'm sorry if the 32-on-64 bit use case was unclear.  I meant the case where (e.g.) LLVM is configured with CC='cc -m32'
and CXX='c++ -m32' on a 64-bit Linux machine.  In this case:
 1) The host triple is x86_64-unknown-linux-gnu
 2) Hence, the default target triple is also x86_64-unknown-linux-gnu
 3) However, the triple required for JIT to work is i386-unknown-linux-gnu

Merely because the user wants a 32-bit compiler that builds 64-bit binaries by default shouldn't be an excuse for us to break the default operation of the JIT.

> With the old JIT, I guess it makes a certain degree of sense to force a triple that we know will work since it doesn't have any sort of 'remote' support, but with the new MCJIT we need to support the remote case, which means being able to generate code for targets other than the host.  Further, MCJIT is designed to be agnostic as to whether or not the user intends to execute the code remotely, so we can never impose the host triple on MCJIT.

This code change isn't imposing a triple on MCJIT.  Remote JIT clients are free to set the module's triple, and this will be respected by MCJIT, and indeed they should do so, as the client is in the best position to know what the required triple is.  A client certainly shouldn't rely on the user having supplied an appropriate triple to LLVM at configure time.

On the other hand, it makes a lot of sense to set up a reasonable default triple for local JIT, as this can be determined reliably by LLVM itself, and it is appropriate for the majority of clients.

> Also, even if we did decide that the host triple should be used for MCJIT if none is specifically provided when creating the Module, the change to remove the explicit triple from the lli invocation in the MCJIT execution engine tests would mean that these tests would behave differently on Windows/MinGW/Cygwin (where it will use the target triple + '-elf') and other platforms (where it would use the host triple).

That is correct.  I will see if I can adjust lit.cfg to extract the correct triple in this case.  (I don't think I have a Windows machine to test against, though.)

Thanks,
--
Peter