llvm dev - May 2015 - [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com>
wrote:
> This is the key question. The LLVM assumption is that these sorts of things
> are inferable from the triple. Your observation here that the GNU world’s
> notion of triples and LLVM’s need not be the same is a good one. Having a
> split and a translation up in clang seems an interesting avenue to explore.
> I suspect this won’t be the last of this sort of issue you’ll encounter,
> unfortunately. Smarter LLVM layer triples is very worth exploring.
IIRC, some people were exploring moving all options to
-march/-mcpu/-mfpu and other -m options (like os, abi, release)
instead of using triples.

It'll be easier to convince other compiler to support -m options than
to support a whole new type of triple/tuple.

cheers,
--renato

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 23 May 2015 11:19
> To: Jim Grosbach
> Cc: Daniel Sanders; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to
> MCObjectFileInfo
> 
> On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote:
> > This is the key question. The LLVM assumption is that these sorts of
things
> > are inferable from the triple. Your observation here that the GNU
world’s
> > notion of triples and LLVM’s need not be the same is a good one.
Having a
> > split and a translation up in clang seems an interesting avenue to
explore.
> > I suspect this won’t be the last of this sort of issue you’ll
encounter,
> > unfortunately. Smarter LLVM layer triples is very worth exploring.
>
> IIRC, some people were exploring moving all options to
> -march/-mcpu/-mfpu and other -m options (like os, abi, release)
> instead of using triples.
> 
> It'll be easier to convince other compiler to support -m options than
> to support a whole new type of triple/tuple.
> 
> cheers,
> --renato
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.

As an example, here's a sketch of how I see the creation of MCAsmInfo
changing in llvm-mc.cpp. At the moment it's:
	MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); //
MCTargetOptions::ABIName set to the value of -target-abi
	TripleName = Triple::normalize(TripleName); 
	Triple TheTriple(TripleName); 
	...
	std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI,
TripleName));
	assert(MAI && "Unable to create target asm info!");
and it would become something like:
	MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); //
MCTargetOptions::ABIName no longer exists
	TargetTuple TheTuple(GNUTriple(TripleName).getTargetTuple());
	...
	// We can factor this block into a function
	if (... arguments have -EL ...)
	  TargetTuple.setEndian(Little);
	if (...arguments have -mabi=X ...)
	  TargetTuple.setABI(ABI);
	... etc. ...
	...
	std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI,
TheTuple));
	assert(MAI && "Unable to create target asm info!");
the user is still able to use GNU triples as they did before.

As another example, here's the creation of MCAsmInfo in IRObjectFile.cpp:
	StringRef Triple = M->getTargetTriple(); // Currently a GNU triple. 
	std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Triple));
	if (!MAI) 
	  return; 
	...
	MCTargetOptions MCOptions; // MCTargetOptions::ABIName is not initialized since
there are no arguments to parse.
As another example, here's the creation of MCAsmInfo in IRObjectFile.cpp:
	TargetTuple Tuple(M->getTargetTriple()); // Now an LLVM tuple and contains
the ABI name.
	std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Tuple));
	if (!MAI) 
	  return; 
	...
	MCTargetOptions MCOptions; // MCTargetOptions::ABIName no longer exists.

> On May 26, 2015, at 6:58 AM, Daniel Sanders <Daniel.Sanders at
imgtec.com> wrote:
> 
>> -----Original Message-----
>> From: Renato Golin [mailto:renato.golin at linaro.org]
>> Sent: 23 May 2015 11:19
>> To: Jim Grosbach
>> Cc: Daniel Sanders; LLVM Developers Mailing List (llvmdev at
cs.uiuc.edu)
>> Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to
>> MCObjectFileInfo
>> 
>> On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com>
wrote:
>>> This is the key question. The LLVM assumption is that these sorts
of things
>>> are inferable from the triple. Your observation here that the GNU
world’s
>>> notion of triples and LLVM’s need not be the same is a good one.
Having a
>>> split and a translation up in clang seems an interesting avenue to
explore.
>>> I suspect this won’t be the last of this sort of issue you’ll
encounter,
>>> unfortunately. Smarter LLVM layer triples is very worth exploring.
>> 
>> IIRC, some people were exploring moving all options to
>> -march/-mcpu/-mfpu and other -m options (like os, abi, release)
>> instead of using triples.
>> 
>> It'll be easier to convince other compiler to support -m options
than
>> to support a whole new type of triple/tuple.
>> 
>> cheers,
>> --renato
> 
> 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.
Yep. I completely agree that having a significantly different user-facing triple
structure would be a much different thing.

The advantage here is that we can put quite a lot of this translation stuff into
per-target hooks and such (where it makes sense).
> 
> As an example, here's a sketch of how I see the creation of MCAsmInfo
changing in llvm-mc.cpp. At the moment it's:
> 	MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); //
MCTargetOptions::ABIName set to the value of -target-abi
> 	TripleName = Triple::normalize(TripleName); 
> 	Triple TheTriple(TripleName); 
> 	...
> 	std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI,
TripleName));
> 	assert(MAI && "Unable to create target asm info!");
> and it would become something like:
> 	MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); //
MCTargetOptions::ABIName no longer exists
> 	TargetTuple TheTuple(GNUTriple(TripleName).getTargetTuple());
> 	...
> 	// We can factor this block into a function
> 	if (... arguments have -EL ...)
> 	  TargetTuple.setEndian(Little);
> 	if (...arguments have -mabi=X ...)
> 	  TargetTuple.setABI(ABI);
> 	... etc. ...
> 	...
> 	std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI,
TheTuple));
> 	assert(MAI && "Unable to create target asm info!");
> the user is still able to use GNU triples as they did before.
> 
> As another example, here's the creation of MCAsmInfo in
IRObjectFile.cpp:
> 	StringRef Triple = M->getTargetTriple(); // Currently a GNU triple. 
> 	std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Triple));
> 	if (!MAI) 
> 	  return; 
> 	...
> 	MCTargetOptions MCOptions; // MCTargetOptions::ABIName is not initialized
since there are no arguments to parse.
> As another example, here's the creation of MCAsmInfo in
IRObjectFile.cpp:
> 	TargetTuple Tuple(M->getTargetTriple()); // Now an LLVM tuple and
contains the ABI name.
> 	std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Tuple));
> 	if (!MAI) 
> 	  return; 
> 	...
> 	MCTargetOptions MCOptions; // MCTargetOptions::ABIName no longer exists.

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