Cleaning up ARM parts of the Clang driver

Hi James,

I can answer some of your questions, and most of them is: legacy.

Everything that could be inferred from triple or somewhere else is
there because that's what used to be. There needs to be a clean up,
both in Clang and llc to make the arguments less confusing. And all
legacy (gcc or otherwise) should be marked as so (at least with
comments). But, as you can see below, it's never that simple... :wink:

2: The driver currently tries to pick a default CPU for the architecture if
none is specified. I think this is wrong – if no CPU is specified then the
compiler should *not* tune for a specific CPU. The user would expect if
specifying –arch armv7, for the compiler to give an output that has good
blended performance on all armv7 cores, not cortex-a8 specifically for
example.

This is not as bad. Targeting ARM7T will produce code that runs on
almost every ARM platform (AFAIK). I believe Intel has the same idea
with x86.

I don't think LLVM has any optimization specific to ARM7...

It’s not evident why this code is here. Why does –msoft-float disable NEON?
NEON has an integer vectoriser too. GCC relic?

This is nonsense, but be careful. If I recall correctly, hasVFP()
returns true is the unit has NEON, so you might end up selecting VFP
instructions even when asking for softfp.

The ARM back-end has to account for that before you can decouple VFP of NEON.