Hi, On 11/18/20, 10:17 AM, "Wilco Dijkstra" <wilco.dijks...@arm.com> wrote: > I presume you're trying to unify the --with- options across most targets?
Yes, my intention was to provide the same configure options on arm64 as on x86, such that projects that already use those options can change cpu name to "neoverse-n1" and that will build a compiler with the right tuning for Graviton2. Allowing arm64 users to specify all the flags available on x86 is important. > That would be very useful! However there are significant differences > between > targets in how they interpret options like --with-arch=native (or -march). > So > those differences also need to be looked at and fixed to avoid unexpected > results. > > As for the first patch, I think support for --witch-tune requires more > changes. > Without proper processing of a --with-tune, you get an incorrect > architecture > version (if say the CPU you tune for is newer than the --with-cpu/arch > or default). > > I posted patches to add --with-tune and fix various issues a while back: > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553865.html > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553866.html Thanks for pointing me to your patches, I was not aware of these changes. I see that your patches enable more use cases and fix several bugs. These changes would definitely be good to have in trunk and branches. My patch was the minimal change to enable --with-tune=neoverse-n1 > As for your second patch, --with-cpu-64 could be a simple alias indeed, > but what is the exact definition/expected behaviour of a --with-cpu-32 > on a target that only supports 64-bit code? The AArch64 target cannot > generate AArch32 code, so we shouldn't silently accept it. IMO allowing users to specify all the flags available on x86 is important. Thanks, Sebastian
