[llvm-commits] [PATCH] Re-introduce llvm::sys::getHostTriple() function.
joerg at britannica.bec.de
Fri Jan 4 11:59:15 PST 2013
On Fri, Jan 04, 2013 at 11:48:42AM -0800, Peter Collingbourne wrote:
> On Sun, Dec 30, 2012 at 05:47:36PM -0800, Joerg Sonnenberger wrote:
> > The problem I have with this is that there are three pretty much unrelated concepts:
> > (1) The default target of the compiler
> > (2) The platform LLVM was built in
> > (3) The platform LLVM is running on
> > The current answer is the (1) and (3) are identical unless the user
> > explicitly specifies something else. This is important if you
> > consider building and running on a bi-size platform like X86. What
> > is the correct and/or preferable choice -- 64bit or 32bit code?
> > Solaris for example still has a mostly 32bit user land as the
> > majority of programs don't get any benefits (but certain penalties)
> > when compiled as 64bit code. So far I haven't seen a good argument
> > that making (1) and (3) separate switches/choices is useful. At the
> > very least, the name "getHostTriple" doesn't reflect it either,
> > since i386 might very well be a saner default for JIT on x86.
> Consider the case where LLVM is configured to act as a cross compiler
> by default (using --target=). This configuration would break the
> JIT if we assume (1) and (3) are always the same, unless the client
> sets the host triple correctly. But this then pushes the problem of
> figuring out the correct host triple to the client, while it could
> be done in a standard way inside LLVM.
A patient comes to the doctor and says "Every time I drink coffee, I
feel a sudden pain in my eye." The doctor replies: "Have you considered
taking out the spoon?"
This kind of feels like that case. I don't think you understood my
argument correctly. If I have a 32bit binary, if anything, JIT should
default to 32bit code. That is not the same as the default triple when
building a cross-compiler. It is also not correct to query the system
platform, since at least for NetBSD/amd64 running a i386 binary, it will
say amd64. As such, I don't see how introducing getHostTriple provides
an improvement over using the default target.
More information about the llvm-commits