This is the mail archive of the gcc-bugs@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]

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to UroÅ Bizjak from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> 
> > I'd say the i386 backend just should add a new constraint for CONST0_RTX
> > only and use it wherever the all ones is not allowed.  As "C" is documented,
> > probably the new "BC" constraint should be const0/CONST0_RTX only, and I
> > think at least the vector_move_operand, reg_or_0_operand and likely the
> > const_int_operand cases too should be changed to "BC".  At least that way
> > the RA and other spots will not try to satisfy it with something that can't
> > match.
> 
> Yes, let's go this way.

Ok, will work on it tomorrow.
> 
> > And then there is the question if and what should change on the LRA side.
> 
> IMO, to avoid issues like this, ICE with unrecognized insn should be
> triggered when operand satisfies constraint, but not predicate.

If I manually set INSN_CODE to -1 when recog in lra fails, I get the ICE later
on.

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