On Wed, 17 Jan 2024 19:19:58 PST (-0800), monk.chi...@sifive.com wrote:
Thanks for your advice!! I agree it should be fixed in the RISC-V backend
when expansion.
On Wed, Jan 17, 2024 at 10:37 PM Jeff Law <jeffreya...@gmail.com> wrote:
On 1/17/24 05:14, Richard Biener wrote:
> On Wed, 17 Jan 2024, Monk Chiang wrote:
>
>> This allows the backend to generate movcc instructions, if target
>> machine has movcc pattern.
>>
>> branchless-cond.c needs to be updated since some target machines have
>> conditional move instructions, and the experssion will not change to
>> branchless expression.
>
> While I agree this pattern should possibly be applied during RTL
> expansion or instruction selection on x86 which also has movcc
> the multiplication is cheaper. So I don't think this isn't the way to
go.
>
> I'd rather revert the change than trying to "fix" it this way?
WRT reverting -- the patch in question's sole purpose was to enable
branchless sequences for that very same code. Reverting would regress
performance on a variety of micro-architectures. IIUC, the issue is
that the SiFive part in question has a fusion which allows it to do the
branchy sequence cheaply.
ISTM this really needs to be addressed during expansion and most likely
with a RISC-V target twiddle for the micro-archs which have
short-forward-branch optimizations.
IIRC I ran into some of these middle-end interactions a year or two ago
and determined that we'd need middle-end changes to get this working
smoothly -- essentially replacing the expander checks for a MOVCC insn
with some sort of costing.
Without that, we're just going to end up with some missed optimizations
that favor one way or the other.
jeff
