https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123313
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|120763 |
--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So I took a look at this from a target perspective for completeness sake. I'm
even more convinced that the ifcvt.cc approach is better. I can see patterns
we could target in the machine description, but doing so would likely need to
be a define_insn_and_split as they'd be 4->3, 3->3 or similar cases. I don't
see a viable 4->2 or 3->2 pattern for a simple define_split. This is the
closest:
(set (reg/v:DI 136 [ b ])
(plus:DI (if_then_else:DI (eq:DI (reg:DI 140)
(const_int 0 [0]))
(plus:DI (reg:DI 11 a1 [ b ])
(const_int 1 [0x1]))
(const_int 0 [0]))
(const_int -1 [0xffffffffffffffff])))
That has all the elements we want. But it's still a 3 instrution pattern,
seq+addi+or, so at best its a 3->3 insn-and-split.
By attacking in ifcvt.cc we can generate a sequence, whatever length it may be,
and let the cost model determine if it's profitable. ifcvt.cc also has the
advantage that it doesn't require zicond as an intermediate step for riscv.
So next step is to try and take that POC to completion.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
[Bug 120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting
