This is the mail archive of the gcc@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: IA-64 ICE on integer divide due to trap_if and cfgrtl


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


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