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