[LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

[Daniel Sanders]

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