FW: [PATCH] Driver modifications for cross compilation

Hi all,

As part of this patch I've noticed a part of the driver that interacts badly
with these changes.

driver.cpp:ParseProgName looks for a prefix on the name of the clang
executable (arm-none-eabi-clang, for example), and sets the target triple
accordingly. It does this in what I would consider an incorrect way however,
by forging a "-ccc-host-triple" argument and prepending it to the argument
list.

My patch assumes that if -ccc-host-triple is specified, it is specified by
the user and as such overrides any -mcpu=/-march=/-mos= inferred choice. I'd
argue that the correct behaviour in ParseProgName should be to set
Driver::DefaultHostTriple.

This would function as a hint or a starting point for the architecture
detection code, and allow -march=/-mos=/-mcpu= to override it.

The triple selection could then be pictured as a hierarchy, with lower
levels overriding those above:

  * llvm::sys::getHostTriple()
  * Any inferred executable prefix (ParseProgName)
  * Any -march, -mcpu or -mos arguments.
  * -ccc-host-triple

Do you have any thoughts on this? functionally I can't see how it would have
any change from the current mechanism (which is the same as the above
hierarchy minus the third item).

Cheers,

James

I disagree that -ccc-host-triple should override -mcpu/-march etc.
That's just not the way how many toolchains work. In fact, it is
completely contrary to how most systems operate.

Consider the NetBSD cross-compiling toolchain as one of the most
integrated systems in this regard. The target triple is fixed for each
architecture (i486--netbsdelf, x86_64--netbsd, etc.). If the user wants
to optimise for a specific CPU, she can add -mcpu or -march via the
appropiate variables. It doesn't make sense to change the target triple
for that.

ParseProgName works this way as it makes sure that only local state is
modified. That feels a lot cleaner than adjusting global variables.
Consider a clang daemon as an example that might be useful to implement
at some point.

Joerg

Hi Joerg,

> My patch assumes that if -ccc-host-triple is specified, it is
specified by
> the user and as such overrides any -mcpu=/-march=/-mos= inferred
choice. I'd
> argue that the correct behaviour in ParseProgName should be to set
> Driver::DefaultHostTriple.

I disagree that -ccc-host-triple should override -mcpu/-march etc.
That's just not the way how many toolchains work. In fact, it is
completely contrary to how most systems operate.

Consider the NetBSD cross-compiling toolchain as one of the most
integrated systems in this regard. The target triple is fixed for each
architecture (i486--netbsdelf, x86_64--netbsd, etc.). If the user wants
to optimise for a specific CPU, she can add -mcpu or -march via the
appropiate variables. It doesn't make sense to change the target triple
for that.

Personally, I'm more than happy to only use -mcpu/-march and friends,
however
I see the power in specifying the triple and I'd expect resistance to
removing it
or diluting its power.

Your argument seems to be that functionally, -ccc-host-triple should have
less priority
than -march and friends. Is my interpretation correct? If so, I'm perfectly
happy with
this as long as the community doesn't object.

ParseProgName works this way as it makes sure that only local state is
modified. That feels a lot cleaner than adjusting global variables.
Consider a clang daemon as an example that might be useful to implement
at some point.

Given the above debate this is probably a moot point, but I feel that
calling a setter
in a Driver& object that is already passed into that function is cleaner
than adding
an additional invisible argument *.

Cheers,

James

* Relevant hunk of the diff:

   std::string IgnoredError;
   if (llvm::TargetRegistry::lookupTarget(Prefix, IgnoredError)) {
- ArgVector.insert(&ArgVector[1],
- SaveStringInSet(SavedStrings, Prefix));
- ArgVector.insert(&ArgVector[1],
- SaveStringInSet(SavedStrings, std::string("-ccc-host-triple")));
+ TheDriver.setDefaultHostTriple(Prefix);
   }
}

Your argument seems to be that functionally, -ccc-host-triple should have
less priority than -march and friends. Is my interpretation correct?
If so, I'm perfectly happy with this as long as the community doesn't
object.

Essentially.

> ParseProgName works this way as it makes sure that only local state is
> modified. That feels a lot cleaner than adjusting global variables.
> Consider a clang daemon as an example that might be useful to implement
> at some point.

Given the above debate this is probably a moot point, but I feel that
calling a setter
in a Driver& object that is already passed into that function is cleaner
than adding
an additional invisible argument *.

I don't care too much either way.

Joerg