This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 28 Jan 2016 17:49:59 +0000
- Subject: [Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64
- Auto-submitted: auto-generated
- References: <bug-69459-4 at http dot gcc dot gnu dot org/bugzilla/>
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.