[cfe-dev] Cleaning up ARM parts of the Clang driver

[Renato Golin]

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... ;)


On 4 October 2011 12:09, James Molloy <james.molloy at arm.com> wrote:
> 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.


-- 
cheers,
--renato

http://systemcall.org/