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! :slight_smile:

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.

Could you have a constructor for TargetTuple(string) to build a triple
on its own?

--renato

I currently plan to use TargetTuple(string) for parsing serialized TargetTuples.

Right.

A temporary solution would be a static method
TargetTuple::fromTripleString(string), that we remove once the triple
is replaced.

cheers,
--renato