[sending again as the email seems to have not delivered] Hi Richard,
> On 7 Jun 2025, at 1:12 am, Richard Sandiford <richard.sandif...@arm.com>
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> 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...
>
I changed it to:
+# Special case cpu_type for x86_64 as it shares AUTO_PROFILE from i386.
+if test "${cpu_type}" = "x86_64" ; then
+ cpu_type="i386"
+fs
Is this ok? Tested on x86_64 and aarch64 linux-gnu.
Thanks,
Kugan
0001-AutoFDO-Fix-profile-bootstrap-for-x86_64.patch
Description: 0001-AutoFDO-Fix-profile-bootstrap-for-x86_64.patch
