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 11:47:33AM -0400, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@false.org> writes:
>
> > 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.
I'm still investigating, but it looks like flow explicitly refuses to
handle comparisons which are not against (const_int 0) - but
HAVE_conditional_execution support doesn't. Am I the first person
foolish enough to try to use cond_exec patterns without cc0?
> > 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.
>
> Isn't there something a bit strange about that? If reg 66 holds a
> QImode value, can you really do an SImode compare? How do you know
> what is in the upper bits of the register?
>
> Should you be defining PROMOTE_MODE?
I do define PROMOTE_MODE. It looked like this before combine:
(set (reg:QI 65) (mem:QI (reg:SI 55)))
(set (reg:SI 66) (zero_extend:SI (reg:QI 65))
(set (pc) (if_then_else (ne (reg:SI 66) (const_int 1)))
(label_ref 1)
(pc))
Because we have LOAD_EXTEND_OP defined to ZERO_EXTEND, combine will
transform that to:
(set (reg:QI 65) (mem:QI (reg:SI 55)))
(set (pc) (if_then_else (ne (subreg:SI (reg:QI 65)) (const_int 1)))
(label_ref 1)
(pc))
--
Daniel Jacobowitz