[LLVMdev] The Trouble with Triples (original) (raw)

Daniel Sanders Daniel.Sanders at imgtec.com
Thu Jul 30 07:03:22 PDT 2015

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

More information about the llvm-dev mailing list