This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: IA-64 ICE on integer divide due to trap_if and cfgrtl
- From: Ian Lance Taylor <iant at google dot com>
- To: Jim Wilson <wilson at tuliptree dot org>
- Cc: gcc <gcc at gcc dot gnu dot org>
- Date: Mon, 14 Apr 2008 21:27:47 -0700
- Subject: Re: IA-64 ICE on integer divide due to trap_if and cfgrtl
- References: <1208225539.3391.60.camel@localhost.localdomain>
Jim Wilson <wilson@tuliptree.org> writes:
> It seems odd that cfgrtl allows a conditional trap inside a basic block,
> but not an unconditional trap. The way things are now, it means we need
> to fix up the basic blocks after running combine or any other pass that
> might be able to simplify a conditional trap into an unconditional trap.
>
> I can work around this in the IA64 port. For instance I could use
> different patterns for conditional and unconditional traps so that one
> can't be converted to the other. Or I could try to hide the conditional
> trap inside some pattern that doesn't get expanded until after reload.
> None of these solutions seems quite right.
>
> But changing the basic block tree during/after combine doesn't seem
> quite right either.
>
> The other solution would be to fix cfgbuild to treat all trap
> instructions are control flow insns, instead of just the unconditional
> ones. I'm not sure why it was written this way though, so I don't know
> if this will cause other problems. I see that sibling and noreturn
> calls are handled the same way as trap instructions, implying that they
> are broken too.
I think the current cfgbuild behaviour is just to avoid putting a
barrier in the middle of a basic block. A conditional trap
instruction is not necessarily a control flow instruction for the
compiler--it's similar to a function call which may or may not return.
An unconditional trap is similar to a function call which is known to
not return.
I guess the difference is that combine can't turn a function call
which may or may not return into a function call which will not
return.
Since traps are uncommon, and since you can't do a lot of optimization
around them anyhow, it's probably OK to make them always return true
from control_flow_insn_p. At least it's worth trying to see if
anything breaks.
Ian