https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #17)
> > No you got it wrong.
> > _121 will either be -1 or 0. _11 should be -1 or 0 too.
> > So the question is what was the VEC_EXTRACT doing the right thing? Is it
> > 0/-1 or 0/1?
>
> I literally mentioned VEC_EXTRACT in the message directly below as well as
> specified that it's the sequence, not the negate... But thanks for
> confirming.
>
> And we are creating the vector to extract from directly in the expander so a
> sign extend won't help. We'd need to
>
> rtx ones = gen_const_vec_duplicate (qimode, GEN_INT (-1));
>
> in the BI expander. But that breaks pr114668.c. Need to think about it
> some more.
This is why I mentioned that maybe vec_extract<mode>bi's setting operand maybe
should be a BI subreg of QI. So you still get 0/1 in the QI and then that will
be sign extended (or zero extended) by the middle-end.
Something like:
```
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 92e6942b523..c484e9f3c70 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -1451,14 +1451,16 @@ (define_expand "vec_extract<mode>qi"
;; Same for a BImode but still return a QImode.
(define_expand "vec_extract<mode>bi"
- [(set (match_operand:QI 0 "register_operand")
- (vec_select:QI
+ [(set (match_operand:BI 0 "register_operand")
+ (vec_select:BI
(match_operand:VB_VLS 1 "register_operand")
(parallel
[(match_operand 2 "nonmemory_operand")])))]
"TARGET_VECTOR"
{
- emit_insn (gen_vec_extract<mode>qi (operands[0], operands[1], operands[2]));
+ rtl qir = gen_reg (QImode);
+ emit_insn (gen_vec_extract<mode>qi (qir, operands[1], operands[2]));
+ emit_move_insn (operands[0], gen_lowpart (BImode, qir));
DONE;
})
```
Note I didn't try this at all and I am not 100% sure BImode will work as a
subreg of QImode though.
