[LLVMdev] The Trouble with Triples

[Daniel Sanders]

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 30 July 2015 00:11
> 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 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.

Definitely. It's better to be discussing it now rather than (currently) 30 big patches later when I reach the patches that change the IR.

> 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.

TargetMachine and many of the others actually hold a llvm::Triple object as their representation of this information. It was a std::string until recently but most users of the member were re-parsing it with llvm::Triple before using it.

> 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

Sure. I'll need some time to transfer it to email and I'm debugging a regression in the 3.7.0 release at the moment so I'll send another email later.