[LLVMdev] The Trouble with Triples
Eric Christopher
echristo at gmail.com
Fri Jul 31 10:56:02 PDT 2015
> 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.
>
>
I agree with the need for serializing information and options into the
module.
>
> > 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.
>
>
Metadata won't work. Metadata is defined to not affect code correctness and
this obviously does.
-eric
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/b1f63089/attachment.html>
More information about the llvm-dev
mailing list