[llvm-dev] The Trouble with Triples

[Daniel Sanders via llvm-dev]

> > > The question I want to ask here is: What about API users? Things
> > > like JIT's and debuggers will want the same defaults (possibly
> > > augmented by auto-detection). One nice thing about handling
> > > this in the Triple/TargetTuple boundary was that these users
> > > get the same behaviour as clang in all areas of LLVM.
> >
> > Only the compiler driver is impacted by customised meanings of
> > triples. It is a JIT’s responsibility to know what it is targeting
> > and if that needs to match the host compiler then that information
> > needs to be extracted from the pre-processor breadcrumbs available
> > when compiling the JIT driver itself which describe the options the
> > JIT driver is being built with; these then have to be translated into
> > TargetMachine settings. A JIT won’t know what triple to use let alone
> > the other data without taking it from its own build environment.

There's llvm::sys::getDefaultTargetTriple() but taking it from its own
configure script or similar makes sense.

> > For disassemblers a similar story applies the information needs to be taken
> > from the ELF though this time and anything missing is a failing of the
> > MIPS ELF format which would need extending to carry the information.
> > .MIPS.abiflags helps massively here though.

I've realized the bit I'm missing on the debugger side. When there is no ELF,
it's the target and/or users responsibility to tell the debugger what it is.

> JIT users already have to construct the TargetMachine. As do debugger
> users. ...

That's right. The TargetMachine is constructed from a Triple (and other arguments).

The thing I'm trying to clarify is which CPU is selected for the following calls:
  createTargetMachine("mips-linux-gnu", "", "", ...)
  createTargetMachine("mips-linux-gnu", "generic", "", ...)
  createTargetMachine("mips-linux-gnu", "native", "", ...)

At the moment, all three will select mips32 but I believe "native" and "generic"
should have a platform dependent minimum (i.e. MIPS-II on Debian, MIPS32R2 on
Fedora) in the same way a clang's default will be platform dependent.

> > b) The lack of a TargetMachine at the MC level was something I brought up a long time ago in
> > this thread with my proposed solutions. This is what needs to be fixed, especially given that targets
> > can switch ISA, ABI, floating point, etc within a single assemble action.
>
> This is somewhat off-topic but just for my own knowledge. When you say 'ABI' here do you mean
> the register names or the wider ABI? I'm aware we can change register names but I don't think
> we can change the actual ABI on the fly.
>
> Wider ABI, i.e. something like .set fpmath= could change the ABI for surrounding functions. I'm... disappointed at how that works in the ELF flags case, but it might be less of an issue.
>
> -eric

(The closest I could find to '.set fpmath=' is '.set fp=' so I guess you mean that.)

Switching between FP32/FP64/etc. makes sense to me. Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150924/eb692ecb/attachment.html>