[LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

[Jim Grosbach]

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