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.> 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
> -----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, > --renatoThat makes sense to me. What would we do if the metadata is absent for some reason?
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
> 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>
On 31 July 2015 at 18:56, Eric Christopher <echristo at gmail.com> wrote:> Metadata won't work. Metadata is defined to not affect code correctness and > this obviously does.That's a good point... But I think we're going around in circles already... :( Should we try something more efficient? Like a hangout or something? cheers, --renato
> On Jul 31, 2015, at 10:56 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On 30 July 2015 at 14:52, Daniel Sanders <Daniel.Sanders at imgtec.com <mailto: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.Is it true for Module level Metadata and not only for instruction attached one? Thanks, — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/ce4866bb/attachment.html>