On 29 July 2015 at 21:44, Eric Christopher <echristo at gmail.com> wrote:> I'm not sure I agree with the basic idea of using the target triple as a way > of encoding all of the pieces of target data as a string.Hi Eric, That's not the idea at all. The Triple object will remain unchanged. The Tuple will be the API to handle getting/setting parameters depending on the Triple, compiler flags, attributes, etc. There will be no string representation of all options, as that would be impossible, or at least, highly undesirable, especially in the IR. The Tuple is for the sole use of front-ends, middle-ends and back-ends to communicate and understand the *same* meaning regarding the *same* input. Having a Tuple class that encodes details of the targets go a long way to ensure that, since you can directly pass the Tuple when you build the Target objects, and the information it provides will be identical, no matter where it is. Right now, we have multiple representations of the targets' information because the Triple object cannot encode every aspect of them, especially problematic between Clang and LLVM. The decision to create a new class (Tuple) is because Triple already has a legacy-heavy meaning, which should not change. This is not about the serialization of the target information, but rather the consistent manipulation of it inside the compiler.> My suggestion on a route forward here is that we should look at the > particular API and areas of the backend that you're having an issue with and > figure out how to best communicate the data you'd like to the appropriate > area.That is precisely what he's doing. :) cheers, --renato
> > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > >This part doesn't seem obvious from the direction the patches are going.> There will be no string representation of all options, as that would > be impossible, or at least, highly undesirable, especially in the IR. > >Yes.> The Tuple is for the sole use of front-ends, middle-ends and back-ends > to communicate and understand the *same* meaning regarding the *same* > input. > >Definitely don't want this in the middle end at all. That all can be part of the TargetMachine/TargetSubtargetInfo interface.> Having a Tuple class that encodes details of the targets go a long way > to ensure that, since you can directly pass the Tuple when you build > the Target objects, and the information it provides will be identical, > no matter where it is. Right now, we have multiple representations of > the targets' information because the Triple object cannot encode every > aspect of them, especially problematic between Clang and LLVM. > >This part I agree with.> The decision to create a new class (Tuple) is because Triple already > has a legacy-heavy meaning, which should not change. > >Agreed with at least the "because" part.> This is not about the serialization of the target information, but > rather the consistent manipulation of it inside the compiler. > > > > My suggestion on a route forward here is that we should look at the > > particular API and areas of the backend that you're having an issue with > and > > figure out how to best communicate the data you'd like to the appropriate > > area. > > That is precisely what he's doing. :) > >OK. What's the general class design look like then? The text from the original mail was fairly confusing then as I thought he was doing something that you say he isn't doing :) -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/65e9019b/attachment.html>
On 29 July 2015 at 23:47, Eric Christopher <echristo at gmail.com> wrote:> This part doesn't seem obvious from the direction the patches are going.Until now, most of what he has done was to refactor the Triple class, with no functional change, and to create a thin layer around the Triple (called Tuple) and pass those instead. This is on par with that premise. The current patch is the first one to actually have some more substantial change, so it's good that you stopped it now, before we start breaking everything. Maybe, knowing what it is now, if you could have another quick look at the patch, and see if the new light has helped understand the patch for what it will be. Maybe it's still not good enough, so then we'll have to resort to a new round of design discussions.> Definitely don't want this in the middle end at all. That all can be part of > the TargetMachine/TargetSubtargetInfo interface.Ah, yes! But the TargetMachine (& pals) are created from information from the Triple and the other bits that front-ends keep for themselves. So, in theory, if the Tuple is universal, creating them with a Tuple (instead of a Triple+stuff) will free the front-ends of keeping the rest of the info on their own, and TargetMachine/SubTargetInfo/etc will be more homogeneous across different tools / front-ends than it is today. Another strong point is: we're not trying to change any other machine description / API. This is just about the user options and defaults, that are used to *create* machine descriptions.>> The decision to create a new class (Tuple) is because Triple already >> has a legacy-heavy meaning, which should not change. > > Agreed with at least the "because" part.There was also the name. Triple is very far from the truth. :) But changing the Triple class could cause ripples in the mud that would be hard to see at first, and hard to change later, after people started relying on it. The final goal is that the Triple class would end up as being nothing more than a Triple *parser*, with the current legacy logic, setting up the Tuple fields and using them to select the rest of the default fields.> OK. What's the general class design look like then? The text from the > original mail was fairly confusing then as I thought he was doing something > that you say he isn't doing :)Daniel, can you send your current plan for the Tuple class? cheers, --renato
> There will be no string representation of all options, as that would > be impossible, or at least, highly undesirable, especially in the IR.I just want to double check we're saying the same thing here. We will need a string serialization of the TargetTuple so that we can store it in the IR and read it back. 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.> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: 29 July 2015 23:44 > To: Eric Christopher > Cc: Daniel Sanders; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); Jim > Grosbach (grosbach at apple.com) > Subject: Re: The Trouble with Triples > > On 29 July 2015 at 21:44, Eric Christopher <echristo at gmail.com> wrote: > > I'm not sure I agree with the basic idea of using the target triple as a way > > of encoding all of the pieces of target data as a string. > > Hi Eric, > > That's not the idea at all. > > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > > There will be no string representation of all options, as that would > be impossible, or at least, highly undesirable, especially in the IR. > > The Tuple is for the sole use of front-ends, middle-ends and back-ends > to communicate and understand the *same* meaning regarding the *same* > input. > > Having a Tuple class that encodes details of the targets go a long way > to ensure that, since you can directly pass the Tuple when you build > the Target objects, and the information it provides will be identical, > no matter where it is. Right now, we have multiple representations of > the targets' information because the Triple object cannot encode every > aspect of them, especially problematic between Clang and LLVM. > > The decision to create a new class (Tuple) is because Triple already > has a legacy-heavy meaning, which should not change. > > This is not about the serialization of the target information, but > rather the consistent manipulation of it inside the compiler. > > > > My suggestion on a route forward here is that we should look at the > > particular API and areas of the backend that you're having an issue with and > > figure out how to best communicate the data you'd like to the appropriate > > area. > > That is precisely what he's doing. :) > > 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.> 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