llvm dev - May 2015 - [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

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

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