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

[James Molloy]

> Well, we don't really want to change the behavior for Apple targets
> here.  Given that, if you think you have a better approach, fine.

If (Darwin && v7) Cpu = cortex-a8.

This keeps the current behaviour for Darwin, fits in nicely with the rest of the Darwin special cases, and doesn't need a shedload of switch/cases because the only Cpu with nonstandard behaviour (because it has an Itinerary) is A8. (Excluding A9, which isn't any architectural default).

> The textual representation of the command-line is completely gone by
> the time we invoke CodeGen.  Communicating with CodeGen via sys::cl is
> less than ideal, but nobody has volunteered to clean it up.

Right, sounds like it's there for a reason. I'll keep it and add a FIXME.

Cheers,

James

-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com]
Sent: 04 October 2011 17:12
To: James Molloy
Cc: cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] Cleaning up ARM parts of the Clang driver

On Tue, Oct 4, 2011 at 9:00 AM, James Molloy <james.molloy at arm.com> wrote:
> Hi Eli,
>
>> 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.
>
> We don't actually have any "blended" tuning at the moment...cortex-a8
> tuning is probably at least as good as anything else we have at the
> moment.
>
> Sure; what I was thinking was even though we don't have that sort of tuning,
> it's not right to force a specific core. OK, for ARM, cortex-a8 will
> probably give the best performance all round as it actually has an
> Itinerary, but looking forward that's probably not right.
>
> The main thing is that being able to remove this would remove 50+ lines of
> horrible crufty switch statements, which I think are not needed.

Well, we don't really want to change the behavior for Apple targets
here.  Given that, if you think you have a better approach, fine.

>> 7:
>>   // Setting -mno-global-merge disables the codegen global merge pass.
>> Setting
>>   // -mglobal-merge has no effect as the pass is enabled by default.
>>   if (Arg *A = Args.getLastArg(options::OPT_mglobal_merge,
>>                                options::OPT_mno_global_merge)) {
>>     if (A->getOption().matches(options::OPT_mno_global_merge))
>>       CmdArgs.push_back("-mno-global-merge");
>>   }
>>
>> It seems like this should be better handled by the sys::cl code in llc.
>
> I'm not following.  sys::cl command-line options aren't relevant to
> clang command-line processing.
>
> Apologies, my description made a bit of a leap between tools without
> explaining. -mno-global-merge is passed down from the driver to llc, where
> it is picked up in Target/ARM/ARMTargetMachine.cpp by a sys::cl static. I
> should think that sys::cl should be able to deal with having repeated
> "-mno-global-merge -mglobal-merge" arguments and picking the last one
> itself, instead of the Driver having to do some massaging?

The textual representation of the command-line is completely gone by
the time we invoke CodeGen.  Communicating with CodeGen via sys::cl is
less than ideal, but nobody has volunteered to clean it up.

-Eli


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.