Jeff Law <jeffreya...@gmail.com> writes: > On 11/11/23 08:54, Richard Sandiford wrote: >> Jeff Law <jeffreya...@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
