This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] ira: Don't substitute into TRAP_IF insns (PR78610)
On Wed, Nov 30, 2016 at 1:57 PM, Jeff Law <law@redhat.com> wrote:
> On 11/30/2016 05:52 AM, Richard Biener wrote:
>>
>> On Wed, Nov 30, 2016 at 1:46 PM, Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>>>
>>> In the testcase, IRA propagates a constant into a TRAP_IF insn, which
>>> then becomes an unconditional trap. Unconditional traps are control
>>> flow insns so doing this requires surgery on the cfg.
>>
>>
>> Huh, that's an odd choice ;) I'd say TRAP_IF should be a control-flow
>> insn
>> as well, but well...
>
> Perhaps.
>
> The situation with TRAP_IF reminds me a lot of an indirect call, which after
> some kind of propagation turns into a direct call to a non-returning
> function. It transforms from something that is not control flow in the
> traditional sense to something we do consider control flow.
OTOH the noreturn flag is now on the GIMPLE stmt via
gimple_call_[set_]_ctrl_altering_p and thus the mere
transform into a direct call does _not_ make the call noreturn! It only
opens up the possibility to optimize it so ;) (fixup-cfg does that)
There's also the reverse - an indirect noreturn call transformed to
a direct not noreturn call. This is why we have the flag explicit on the
IL as well (we keep that call as "noreturn" as we have no idea where to
redirect a new fallthru to).
Richard.
> Jeff
>