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

Hi Vedant,

Welcome to the community! :)

On 8 July 2015 at 19:24, Vedant Kumar <vsk at apple.com>
wrote:
> I’ve recently been tasked with cleaning this up.
That's great news! It's one of the biggest driver pains for
complicated targets, like ARM.

>  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.
That's a good plan. It may be easier to do that now and make sure we
don't need to re-parse the triple, but ultimately, both steps will be
replaced by TargetTuple.

TargetParser will parse the triple/cpu/fpu/arch, then TargetTuple will
use that to create a full representation of the target (for now, using
llvm::Triple), then any need for target information would be fulfilled
by that object.

If your work is completed before Daniel gets to work in Clang, it will
likely be a lot simpler for him to implement the Tuple there.

cheers,
--renato

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!

On 9 July 2015 at 10:39, Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:
>         TM.createX(llvm::TargetTuple(llvm::Triple(TripleStr)), ...)
Could you have a constructor for TargetTuple(string) to build a triple
on its own?

--renato