Re: [PATCH 11/12] mode-switching: Add a target-configurable confluence operator

[Richard Sandiford <richard.sandiford@arm.com>]

Jeff Law <jeffreyalaw@gmail.com> writes:
> On 11/11/23 08:54, Richard Sandiford wrote:
>> Jeff Law <jeffreyalaw@gmail.com> writes:
>>> On 11/5/23 11:50, Richard Sandiford wrote:
>>>> The mode-switching pass assumed that all of an entity's modes
>>>> were mutually exclusive.  However, the upcoming SME changes
>>>> have an entity with some overlapping modes, so that there is
>>>> sometimes a "superunion" mode that contains two given modes.
>>>> We can use this relationship to pass something more helpful than
>>>> "don't know" to the emit hook.
>>>>
>>>> This patch adds a new hook that targets can use to specify
>>>> a mode confluence operator.
>>>>
>>>> With mutually exclusive modes, it's possible to compute a block's
>>>> incoming and outgoing modes by looking at its availability sets.
>>>> With the confluence operator, we instead need to solve a full
>>>> dataflow problem.
>>>>
>>>> However, when emitting a mode transition, the upcoming SME use of
>>>> mode-switching benefits from having as much information as possible
>>>> about the starting mode.  Calculating this information is definitely
>>>> worth the compile time.
>>>>
>>>> The dataflow problem is written to work before and after the LCM
>>>> problem has been solved.  A later patch makes use of this.
>>>>
>>>> While there (since git blame would ping me for the reindented code),
>>>> I used a lambda to avoid the cut-&-pasted loops.
>>>>
>>>> gcc/
>>>> 	* target.def (mode_switching.confluence): New hook.
>>>> 	* doc/tm.texi (TARGET_MODE_CONFLUENCE): New @hook.
>>>> 	* doc/tm.texi.in: Regenerate.
>>>> 	* mode-switching.cc (confluence_info): New variable.
>>>> 	(mode_confluence, forward_confluence_n, forward_transfer): New
>>>> 	functions.
>>>> 	(optimize_mode_switching): Use them to calculate mode_in when
>>>> 	TARGET_MODE_CONFLUENCE is defined.
>>> OK.  There's certain similarities between this and the compatible states
>>> we can use to reduce vsetvl instructions in RV-V.   I wonder if Juzhe or
>>> Lehua could utilize this and do less custom optimization code in the RV
>>> backend.
>> 
>> Here's an update based on what you pointed out in 10/12.  The change
>> from last time is to add:
>> 
>>    if (targetm.mode_switching.backprop)
>>      clear_aux_for_edges ();
>> 
>> before the main loop.  Tested as before.
>> 
>> Thanks,
>> Richard
>> 
>> 
>> gcc/
>> 	* target.def (mode_switching.confluence): New hook.
>> 	* doc/tm.texi (TARGET_MODE_CONFLUENCE): New @hook.
>> 	* doc/tm.texi.in: Regenerate.
>> 	* mode-switching.cc (confluence_info): New variable.
>> 	(mode_confluence, forward_confluence_n, forward_transfer): New
>> 	functions.
>> 	(optimize_mode_switching): Use them to calculate mode_in when
>> 	TARGET_MODE_CONFLUENCE is defined.
> OK.  That's the whole set, right?

Yeah, that's everything, thanks.  I've now pushed the series.

Richard