[LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

[Daniel Sanders]

> From: Renato Golin [renato.golin at linaro.org]
> Sent: 26 May 2015 18:43
> To: Daniel Sanders
> Cc: Jim Grosbach; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo
> 
> On 26 May 2015 at 14:58, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> > The intention isn't to change the kind of triples/tuples in use by toolchains and
> > users. There's a lot of legacy and inertia to overcome if we try that. The intention
> > is to map the ambiguous/insufficient GNU triples onto an internal representation
> > as early as possible and pass that internal representation throughout LLVM and
> > the LLVM-IR files. The end-users can still use GNU triples and compiler options
> > such as -EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM
> > tuple.
> 
> Ok, so that will probably involve the Triple / Parser refactoring I'm doing.
> 
> Right now, Triple handles some of that, but it's not authoritative not
> final. I've created an ARMTargetParser class that deals with parsing
> arch/cpu/fpu strings, and I'm moving all string parsing in Clang (LLVM
> is done already) to it. We may also have to move llc, lli and others.
>
> Once this is done, we can begin to move more logic to the Triple in
> the same way, and let target specific Triple management in their own
> classes (like ARMTargetParser), so that Clang doesn't need all
> back-ends to have all arch knowledge. This way, the Triple class will
> be able to take any architecture-specific decision with just strings.
> Such arch-specific classes will, later, be built from a special
> table-gen back-end that will always be enabled for all targets, but
> that's much later.
> 
> The final goal is to keep all that information into one big
> TargetDescription class, which will also help Clang and other users to
> know information about the targets, for instance, what combination of
> environment, ABI and CPU features, to take informed decisions without
> needing any back-end built in.
> 
> Is that in line with your reasoning?
> 
> cheers,
> --renato

Yes, that sounds quite similar to what I'm thinking. The LLVM Tuple concept is essentially your TargetDescription class. I wasn't planning on going as far as ARMTargetParser does since my focus is on the LLVM internals but it makes sense to me and fits nicely with the idea of mutating the LLVM Tuple in response to compiler options.

The steps I'm thinking of for the GNU triple to LLVM Tuple migration are:
* Replace any remaining std::string's and StringRef's containing GNU triples with Triple objects.
* Split the Triple class into Triple and LLVMTuple classes. Both are identical in implementation at this stage except that Triple has a 'getLLVMTuple()' member function.
* Gradually replace Triple's with LLVMTuple's until the public APIs are the only place Triple's are still used.
* Change the internals of LLVMTuple to whatever is convenient.
* Add public API's that use LLVMTuple's and migrate API users (clang, llc, lli, etc.) to the new API.
* Have the API users mutate the LLVMTuple appropriately.

Maybe we can merge our plans and attack it from both directions at the same time.