This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Flow crash for conditional branches against a constant
On Fri, Jun 11, 2004 at 06:00:15PM +0100, Richard Earnshaw wrote:
> On Fri, 2004-06-11 at 16:44, Daniel Jacobowitz wrote:
> > I'm working on a port that has a branch instruction taking an unsigned
> > immediate. Something like this is valid:
> >
> > (set (pc) (if_then_else (ne (reg:SI 66) (const_int 1)))
> > (label_ref 1)
> > (pc))
> >
> > But flow.c completely falls down on this construct. For instance, that will
> > cause not_reg_cond to abort because it is only prepared to handle comparison
> > against 0.
>
> That ought to work. It's exactly like the Thumb cbranch patterns in
> arm.md
Indeed, I just discovered your patch moments ago:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01390.html
It turns out that I was confused. When I use this for conditional
branches, I don't get the aborts in flow. It's when I use it for
define_cond_exec that things break; there are three places in flow
where the condition can be set, and the other two don't have this
check.
Rather than adding it I'm testing removal of the invariant. I don't
see anything besides the boolean arithmetic functions which relies on
the exact form of the condition... yet.
> > Flow also doesn't like this:
> > (set (pc) (if_then_else (ne (subreg:SI (reg:QI 66)) (const_int 1)))
> > (label_ref 1)
> > (pc))
> > It uses REGNO on the first argument without checking for SUBREGs created by
> > combine.
> >
> > Both of these are pretty easy to fix. But are other parts of the compiler
> > going to misbehave also? The relevant section of gccint hasn't been updated
> > in a while; it claims that only (OP (cc0) (const_int 0)) is valid in
> > if_then_else instructions, but this port doesn't use cc0.
>
> Probably some legacy from the fact that flow used to be run only before
> combine (IIRC).
I'll just test the fix then...
--
Daniel Jacobowitz