[LLVMdev] The Trouble with Triples

[Daniel Sanders]

Hi,

For steps 2 and 3, we might get some trivial merge conflicts but nothing that would be a problem for either of us. In these steps, changes to clang and similar will be fairly mechanical. For example:
	TM.createX(TripleStr, ...)
becomes:
	TM.createX(llvm::TargetTuple(llvm::Triple(TripleStr)), ...)
or a prettier variant of it.

Step 7 is probably the step that interacts most with your plan since this step involves non-mechanical changes in clang and will need a single TargetTuple object to mutate (each re-parse will need the options re-applied too). Your work will make this step much simpler so I'd like to get your change in first.

> -----Original Message-----
> From: Vedant Kumar [mailto:vsk at apple.com]
> Sent: 08 July 2015 19:24
> To: Daniel Sanders
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] The Trouble with Triples
> 
> > Another very annoying fact is that the Clang driver re-parses triples many
> > times, and sometimes they change the triple based on a CPU, and then end
> > up with a different CPU.
> 
> I’ve recently been tasked with cleaning this up.
> 
> Before starting on this full gusto, I want to make sure I’m not stepping on
> any toes or duplicating work.
> 
> The rough plan is as follows;
> 
>  1. Replace the call to Driver::computeTargetTriple() in getToolChain() with
>     some variety of ComputeEffectiveClangTriple().
> 
>  2. Cache the result of ComputeEffectiveClangTriple() so we can avoid
>     re-parsing the argument list.
> 
> Daniel -- if this will cause too much interference with steps 2-3 of your
> plan, please let me know.
> 
> vedant
> 
> p.s: I'm rather new to LLVM & Clang. Hello everybody!