On 2023-08-29 09:46  Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
>On 8/28/23 19:28, Fei Gao wrote:
>> On 2023-08-29 06:54  Jeff Law <jeffreya...@gmail.com> wrote:
>>>
>>>
>>>
>>> On 8/28/23 01:47, Fei Gao wrote:
>>>> no functional changes but allow targets to check shrink-wrap-separate 
>>>> enabled or not.
>>>>
>>>>      gcc/ChangeLog:
>>>>
>>>>            * shrink-wrap.cc (try_shrink_wrapping_separate):call
>>>>              use_shrink_wrapping_separate.
>>>>            (use_shrink_wrapping_separate): wrap the condition
>>>>              check in use_shrink_wrapping_separate.
>>>>            * shrink-wrap.h (use_shrink_wrapping_separate): add to extern
>>> So as I mentioned earlier today in the older thread, can we use
>>> override_options to do this?
>>>
>>> If we look at aarch64_override_options we have this:
>>>
>>>     /* The pass to insert speculation tracking runs before
>>>        shrink-wrapping and the latter does not know how to update the
>>>        tracking status.  So disable it in this case.  */
>>>     if (aarch64_track_speculation)
>>>       flag_shrink_wrap = 0;
>>>
>>> We kind of want this instead
>>>
>>>     if (flag_shrink_wrap)
>>>       {
>>>         turn off whatever target bits enable the cm.push/cm.pop insns
>>>       }
>>>
>>>
>>> This does imply that we have a distinct target flag to enable/disable
>>> those instructions.  But that seems like a good thing to have anyway.
>> I'm afraid we cannot simply resolve the confilict based on
>> flag_shrink_wrap/flag_shrink_wrap_separate only, as they're set true from 
>> -O1 onwards,
>> which means zcmp is disabled almostly unless 
>> -fno-shrink-warp/-fno-shrink-warp-separate
>> are explictly given.
>Yea, but I would generally expect that if someone is really concerned
>about code size, they're probably using -Os which (hopefully) would not
>have shrink-wrapping enabled.
>
>>
>> So after discussion with Kito, we would like to turn on zcmp for -Os and 
>> shrink-warp-separate
>> for the speed perfered optimization. use_shrink_wrapping_separate in this 
>> patch provide the
>> chance for this check. No new hook is needed.
>Seems reasonable to me if Kito is OK with it. 

Thanks Jeff and Kito for the discussion.

Could you please review the new series at your convenience?
https://patchwork.sourceware.org/project/gcc/list/?series=24065

BR, 
Fei

>
>jeff

Reply via email to