This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


jeff




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]