Expanding without DONE or FAIL will leave the pattern as well, so this patch is fine IMO, so this patch LGTM, but anyway I will test this and commit if passed :)
On Fri, Jul 14, 2023 at 10:34 AM Palmer Dabbelt <pal...@dabbelt.com> wrote: > > On Thu, 13 Jul 2023 19:02:05 PDT (-0700), li...@eswincomputing.com wrote: > > When generating the gen_and<mode>3 function based on the and<mode>3 > > template, it produces the expression emit_insn (gen_rtx_SET (operand0, > > gen_rtx_AND (<mode>, operand1, operand2)));, which is identical to the > > portion I removed in this patch. Therefore, the redundant portion can be > > deleted. > > > > Signed-off-by: Die Li <li...@eswincomputing.com> > > > > gcc/ChangeLog: > > > > * config/riscv/riscv.md: Remove redundant portion in and<mode>3. > > --- > > gcc/config/riscv/riscv.md | 5 ----- > > 1 file changed, 5 deletions(-) > > > > diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md > > index 7988026d129..c4f8eb9488e 100644 > > --- a/gcc/config/riscv/riscv.md > > +++ b/gcc/config/riscv/riscv.md > > @@ -1491,11 +1491,6 @@ > > DONE; > > } > > } > > - else > > - { > > - emit_move_insn (operands[0], gen_rtx_AND (<MODE>mode, operands[1], > > operands[2])); > > - DONE; > > - } > > }) > > > > (define_insn "*and<mode>3" > > Unless I'm missing something, this will just result in no emitted > instructions for this "and" pattern? That seems wrong, it would at > least have to put the source into the dest -- but > "arith_operand_or_mode_mask" can contain values that don't just result > in an extension (like arbitrary register values, for example), so I > think we need the "and" operation. > > Does this pass the regression suite? > > Either way, if this branch of the conditional can't trigger we should > tighten the constraint (or at a bare minimum add a comment as to why).