[LLVMdev] The Trouble with Triples

Renato Golin renato.golin at linaro.org
Thu Jul 30 08:52:32 PDT 2015


On 30 July 2015 at 15:30, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> I haven't fully researched why the triple is there but one reason is to make backends target the same target as the frontends. Consider the case where clang is used to generate IR and then llc is used to compile it. We currently use the information in the IR to set the GNU triple, the target features, etc.

This already works well, at least for ARM, without necessarily relying
on the target triple in the IR file. Try to strip the target line then
pass it back again via command line. Everything works fine.

I don't know why the triple ended up in the IR, but I think it was the
need to identify the back-end it was tailored to, not necessarily
every detail of the compiler choices. It could easily have been "arm",
"mips", etc. but I guess it ended up as a triple because it was
easier. Most of what triples encode are already present in IR as
function attributes, lowering choices (PCS, ABI, etc), and type sizes.


> That makes sense to me. What would we do if the metadata is absent for some reason?

Nothing.

What you're aiming for is just giving IR more information about
something that can be passed through command line options. Right now,
that's how people use it, so most of the cases, the IR info will be
redundant. Worse still, it could create conflicts if the options are
not completely similar (or have slightly different meanings), which is
bad.

If we're only talking about ARM, I'd put no more than
arch/cpu/fpu/extension in the IR as metadata, to be used in case there
is no other information in the command line, but with the latter
always overriding the behaviour. Mips probably has some other stuff,
x86 has less, as CPU names are more unique than in ARM. Maybe putting
the ABI (GNU, EABI, Darwin) would be a good thing too, to help linking
the objects with the right libraries.

But the lack of information can, and should, be overridden by command
line options. In case there's none, defaults should be used. In that
case, the compiler shouldn't do anything smart on its own, and let the
user see warnings, errors, breakages, etc. We can't control the world
outside the compiler.

cheers,
--renato




More information about the llvm-dev mailing list