> On 9 Apr 2024, at 08:53, Iain Sandoe <idsan...@googlemail.com> wrote:
>
>
>
>> On 9 Apr 2024, at 08:48, Jakub Jelinek <ja...@redhat.com> wrote:
>>
>> On Tue, Apr 09, 2024 at 09:44:01AM +0200, Richard Biener wrote:
>>> (why not do it at each such switch?)
>>
>> Because the traps would then be added even to the bbs which later
>> end up in the middle of the function.
>
> If we defer the unreachable => trap change until expand, then it would
> not affect any of the current decisions made by the middle end.
>
> Since the default expansion of unreachable is to a barrier - would this
> actually make material difference to RTL optimizations?
Here is an implementation of this:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649074.html
Taking a solution to PR109267 out of the equation - it would still be good
to get an answer to the original question “is -funreachable-traps behaving
as expected”? (since it does not substitute in the TU we’ve been discussing)
thanks
Iain
