After re-reading your last couple emails with the benefit of sleep, that all
makes sense to me. The user/driver would be responsible for ensuring each tool
is called with the same options, while each tool is responsible for using the
same TargetTuple in all its calls to LLVM. The only bit I'm unsure about
w.r.t to not having a serialization in the IR is the ModuleLinker where we
currently have code to ensure that all the modules are compatible (by comparing
the triple). Presumably, this code was added because there was a real
possibility of having incompatible modules (i.e. different triples) so we
shouldn't rely on the tool options here. For this the serialization via
metadata makes sense to me. We can then compare and merge TargetTuples with
target-appropriate leniency and/or strictness.
Step 5 is the relevant step of the plan.> 5. Replace serialized Triples with serialized TargetTuples in
LLVM-IR.
> a. Maintain backwards compatibility with IR using triples, at least
for a while.
I don't think we need to change the plan. We're just changing the
serialization format from a string to metadata. I'll need to read up on the
metadata before I can define a serialization.
________________________________________
From: Renato Golin [renato.golin at linaro.org]
Sent: 30 July 2015 16:52
To: Daniel Sanders
Cc: Eric Christopher; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); Jim
Grosbach (grosbach at apple.com)
Subject: Re: The Trouble with Triples
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