Jan Hubicka <hubi...@ucw.cz> writes:
>> Should I go with:
>>
>> +autofdo_target
>>
>> +autofdo_target="i386"
>> +case "${target}" in
>> + aarch64-*-*)
>> + autofdo_target="aarch64"
>> + ;;
>> +esac
>>
>> As in the first version? I can test and send a patch for review if there is
>> no other better alternative.
>
> This looks OK - I can not think of better alternative. At some point we
> need to translate the target CPU to directory name. The build machinery
> is not exactly my strong point, so perhaps someone with more knowledge
> can chime in.
Can we at least keep the variable name as "cpu_type", rather than add
a new classification? I don't see a good reason why autofdo would need
to use its own private naming scheme, rather than sticking to the one
that gcc/configure* already uses (i.e. the one used for gcc/config/<cpu>).
It is incovenient that the toplevel doesn't have access to the logic
used to set that variable though...
Richard
