on 2022-11-28 23:39 Jeff Law<jeffreya...@gmail.com> wrote:
>
>
>On 11/27/22 19:14, Feng Wang wrote:
>> From: wangfeng <wangf...@eswincomputing.com>
>>
>> There is no Immediate operand of ins "rol" accroding to the B-ext,
>> so the immediate operand should be loaded into register at first.
>> But we can convert it to the ins "rori" or "roriw", and then one
>> immediate load ins can be reduced.
>>
>> Please refer to the following use cases:
>> unsigned long foo2(unsigned long rs1)
>> {
>> return (rs1 << 10) | (rs1 >> 54);
>> }
>>
>> The complier result is:
>> li a1,10
>> rol a0,a0,a1
>>
>> This patch will generate one ins
>> rori a0,a0,54
>>
>> gcc/ChangeLog:
>>
>> * config/riscv/bitmanip.md: Add immediate_operand support in rotl
>>RTL pattern
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/riscv/zbb-rol-ror-04.c: New test.
>> * gcc.target/riscv/zbb-rol-ror-05.c: New test.
>
>So this arrived after stage1 close and I'm not aware of an existing BZ
>around this issue, so I'd tend to think this should wait for stage1 to
>re-open in the spring.
>
>
> From a technical standpoint, would it be better to hand this in a more
>generic way? ie, when converting from gimple into RTL, if we want to
>generate a rotate left by immediate and don't have a suitable insn, then
>change it to a rotate right by an adjusted immediate. This could
>probably be done in optabs.cc::expand_binop.
>
>
>We might need similar code in combine.cc or simplify-rtx.cc since some
>rotate cases (or exposure of the constant) may not show up until later
>in the RTL pipeline.
>
>
>Anyway, doing this in a more generic way seems like it's worth
>investigating.
>
>
>jeff
>
Hi jeff,
Thanks for your reply. In the currently it will judge the rotate shift number
when converting from
gimple into RTL, if the shift number bigger than mode_size/2, then reverse the
rotate direction.
I think the purpose of this process is to handle rotate shift quickly. I will
think about your advice
and try to modify it in the expand pass.
Wang Feng
Best regards
