[shrink-wrap] should not sink instructions which may cause trap ?

Jeff Law law@redhat.com
Fri Sep 26 16:13:00 GMT 2014

On 09/26/14 08:50, Jiong Wang wrote:

>>>>     if (may_trap_p (x))
>>>>       don't sink this instruction.
>>>>      any comments?
>>> Should be checking if x may throw internally instead.
>> Richard, thanks for the suggestion, have used insn_could_throw_p to do
>> the check,
>> which will only do the check when flag_exception and
>> flag_non_call_exception be true,
>> so those instruction could still be sink for normal c/c++ program.
>> Jeff,
>>     below is the fix for pr49847.C regression on aarch64. I re-run
>> full test on
>>     aarch64-none-elf bare metal, no regression.
>>     bootstrap ok on x86, no regression on check-gcc/g++.
>>     ok for trunk?
> (re-sent with changelog entry)
> gcc/
> 2014-09-26  Jiong Wang<jiong.wang@arm.com>
>          * shrink-wrap.c (move_insn_for_shrink_wrap): Check
> "insn_could_throw_p" before
>          sinking insn.
I think can_throw_internal, per Richi's recommendation is better.

Note that can_throw_internal keys off the existence of the EH landing 
pads for the particular insn.

If flag_exceptions is false (for example), then would not expect those 
landing pads to exist and the insn would not be considered as 
potentially throwing.

Can you test with can_throw_internal to verify it's behaviour and resubmit


More information about the Gcc-patches mailing list