[LLVMdev] The Trouble with Triples

[Daniel Sanders]

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 30 July 2015 15:07
> 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 14:52, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> > We will need a string serialization of the TargetTuple so that we can store it
> in the IR and read it back.
> 
> Why does it have to be in the IR? If every tool that deals with IR has
> the same options and they mean the same thing I don't see why we'd
> need that.

My main reason is that the GNU triple is currently in the IR and I'm trying not to make design changes in the early stages of this work.

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.

One case where tool options isn't sufficient is ModuleLinker::run(). It currently compares the GNU triples to determine whether the IR modules are link-compatible. I'm sure I've seen a couple others but they're not springing to mind at the moment.

> > Whether this is in one piece (e.g. 'target tuple = "...") or multiple pieces
> (e.g. 'target arch = "..."', 'target endian = "..."') doesn't matter too much at
> first but I can see the benefits of the latter being the end point. If we do
> choose that multiple pieces then I'd like to pass through the former first to
> keep the early steps of the migration to a TargetTuple as simple and
> mechanical as possible.
> 
> Assuming we really need it, wouldn't it work if we put in metadata?
> That way, it would bloat the IR of targets that really needed it and
> not the ones that don't, at the same time as being non-critical to
> parsing and validating the IR, so you could safely drop some
> information without breaking the file.
> 
> This would allow more flexibility across targets, if they need
> different types of storage, and would allow targets that do need the
> info to complement the missing info with their own defaults. So we
> could reuse old IR with new IR and still make it work.
> 
> cheers,
> --renato

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