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

[Kaylor, Andrew]

>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.

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.  The best we can do is fail gracefully if the user attempts to execute code that was JITed for a different target -- and depending on how they invoke the code even that may be out of our hands.


>On Wed, Jan 02, 2013 at 02:10:57PM -0800, Andy Kaylor wrote:>>   
>>I also think the changes the the MCJIT execution engine tests and associated lit.cfg file obscure where the triple is coming from
>>in most cases (without actually changing the existing behavior as far as I can tell).
>
> Peter Collingbourne responded:
>Previously the triple came from the default target triple, but now it comes from getHostTriple() in most cases.  I'll add a comment to >lit.cfg to state where the triple is coming from.

In the case of MCJIT the triple for the execution engine is still being taken from the Module to be JITed.  Note that because of the ELF overload on Windows it is necessary to respect the Module's target triple.

Honestly, even after looking at the code it isn't entirely clear to me what happens with lli if the target triple isn't provided on the command line.  It creates the Module using ParseIRFile -> ParseBitcodeFile, and I think that leaves the triple empty if it isn't implicitly provided, so maybe it will use the host triple in these cases, but I don't think it should (for the reasons mentioned above).

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).

-Andy

-----Original Message-----
From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Peter Collingbourne
Sent: Friday, January 04, 2013 12:01 PM
To: reviews+D254+public+7378dfd13274f5ed at llvm-reviews.chandlerc.com
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 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.

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 also think the changes the the MCJIT execution engine tests and associated lit.cfg file obscure where the triple is coming from in most cases (without actually changing the existing behavior as far as I can tell).

Previously the triple came from the default target triple, but now it comes from getHostTriple() in most cases.  I'll add a comment to lit.cfg to state where the triple is coming from.

Thanks,
--
Peter
_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits