[LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

[Renato Golin]

On 27 May 2015 at 22:44, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> 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.

Perfect. This would be my next step, but since you're covering, I
think we can split the work nicely.

My focus now is in restricting the parsing of strings to a single
place. Most architectures are very simple, so a generic TargetParser
would do. But ARM is a huge mess of names and synonyms, so I need a
specialised class.

My final goal is to have your Tuple class handle everything, using my
TargetParser class to initialise the object from strings (like Triple
does) and to validate further changes to the internal state via option
strings, either from the command line, assembly files, etc.

There is a lot of string handling in Clang for options in static
functions all over the place. I'm replacing all ARM ones for
ARMTargetParser calls. This would make easy for you to spot places
where you should add the new Tuple class.

Right now, my parser is just a static class with helper methods, but
once we start having more than one target, we'll need to derive it
from a generic TargetParser, and make it an integral part of the Tuple
class.

Some comments...


> * Replace any remaining std::string's and StringRef's containing GNU triples with Triple objects.

Part of that is done already, with Triple having several enums to hold
the values. But many of those enums are incomplete, especially in the
ARM side. My TargetParser enums are, so far, complete and correct. We
should definitely merge them, though I'll leave it for you to decide
whether to leave it in the parser, or to make the parser depend on the
tuple's enums, or to have a third include file.

Remember that those enums and tables will have to be generated from a
table-gen backend, that will be executed on every build, even if no
targets are built in.


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

I'd call it TargetTuple, not LLVMTuple. :)


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

Sounds like a plan. And one that we can reach each other in the middle
ground in time. I think we can continue with our original plans, and
re-group once we reach it.

cheers,
--renato