[PATCH] [AArch64] Implement Clang CLI interface proposal about "-march".

[Eric Christopher]

>> > 4. Implement support of "-mtune". Usage is: "-march=CPU_NAME". For
>> > instance, "-march=cortex-a57". This option will ONLY get micro-architecture
>> > level feature enabled specifying to target CPU, like "zcm" and "zcz" for
>> > cyclone. Any architecture features WON'T be modified.
>>
>> That's not what -mtune is. According to GCC's manual: "Tune to
>> cpu-type everything applicable about the generated code, except for
>> the ABI and the set of available instructions."
>>
>> The difference between -mcup and -mtune is that the former selects ABI
>> and ISAs supported by the CPU, while the former doesn't. This is
>> particularly important if you want to run the code on a newer CPU but
>> doesn't want to break older ones, so you can't use instructions that
>> the old ones don't have, but you can optimise for the pipeline and
>> branch decisions of the newer CPU, as long as it just slows down the
>> older ones.
>
> I didn't explain it clearly. Your point is totally what I did in this patch.
> I emphasize " ONLY get micro-architecture level feature enabled" is want to
> say ISA won't be changed by this option. This option is to select target CPU
> to optimize for, including enabling micro-architecture level feature,
> choosing MI scheduler and triggering any optimizations specific for target.
>>
>>
>>
>> > 5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is an
>> > alias to "-march={feature of CPU_NAME}+[no]feature" and "-mtune=CPU_NAME"
>> > together. An warning is added to discourage use of this option.
>>
>> I find this one redundant with -march and don't think we should add
>> deprecated features. -mcpu is the flag you want for the behaviour
>> you've done -mtune above. AFAIK, we don't have the infrastructure to
>> implement -mtune yet. Also, the driver is a bit bonkers when going
>> from CPU to Arch from a different arch than the host without using
>> -target (which is the point with -march, I guess).
>>
>> I don't think -mcpu should be used on its own, only in conjunction
>> with -target or -march.
>
> In my patch, the difference between "-mcpu" and "-mtune" is that, "-mcpu"
> will enable all ISAs which target CPU supports, while "-mtune" won't do
> this. And "-mcpu" can accept extra feature modifiers to make a change, but
> "-mtune" accepts CPU name only. So "-mcpu" is an shortcut of "-march" and
> "-tune". Keeping this option alive in clang is because it's still alive in
> gcc, and may still be used in many projects.  An warning is added to
> discourage use of this option.

This is fine, and I encourage the warning. Also, -march should
probably default to -mtune of the same architecture. I didn't read to
verify, but just making sure this is the case.

>>
>>
>>
>>
>> > 1. Neon is enabled by default, and "generic" will be used if no CPU type
>> > is specified.
>>
>> Makes sense to me.
>>
>>
>> > 2. For most scenario, Using "-mtune=CPU" only is recommended as neon is
>> > enabled by default and all micro-architecture optimizations are selected,
>> > and it would provide great compatibility to run on most of AArch64 devices.
>>
>> That'd be -mcpu, and we still need -march or -target.
>
> "-target" is still necessary at moment while "-march" can be omitted
> sometimes, because the settings of default feature can work well for most
> scenarios and provide good code migration. All I want to do is to get
> "-mcpu" supporter happy to use "-mtune" instead. They don't need to complain
> typing too much as splitting "-mcpu" into "-march" and "-mtune" because they
> can use "-mtune" only. For a standard sets of compiling flags, pair use of
> "-march" and "-mtune" is strongly recommended.

This seems to be a good idea. Can you give examples of behavior you're
expecting to see just to verify?

>>
>>
>>
>> > 3. "-march" is designed to be used only if user wants to use crc and
>> > crypto instructions, or disable fp/neon. So "-march" will not be frequently
>> > used and won't bring too much finger burden.
>>
>> I thought the idea was to encourage -march... at least on new targets...
>
> Yes, we always encourage people to specifying architecture features via
> "-march". Letting "-march" and "-mtune" replace "-mcpu" and "-mfpu" is what
> we want to do.

Very much so.

Thanks!

-eric

>>
>>
>> --renato
>
>
>
>
> --
> Best Regards,
>
> Kevin Qin
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>