> On 16 Sep 2017, at 8:59 AM, Segher Boessenkool <[email protected]>
> wrote:
>
> Hi!
>
> On Sat, Sep 16, 2017 at 08:47:03AM +1200, Michael Clark wrote:
>> RISC-V defines promote_mode on RV64 to promote SImode to signed DImode
>> subregisters. I did an experiment on RISC-V to not promote SImode to DImode
>> and it improved codegen for many of my regression test cases, but
>> unfortunately it breaks the RISC-V ABI.
>
> It sounds like you should implement TARGET_PROMOTE_FUNCTION_MODE as well?
riscv currently has default_promote_function_mode_always_promote.
gcc/config/riscv/riscv.c:#define TARGET_PROMOTE_FUNCTION_MODE
default_promote_function_mode_always_promote
I see that default_promote_function_mode_always_promote just calls promote_mode
Is TARGET_PROMOTE_FUNCTION_MODE used to perform canonicalisation before calls
and returns? i.e. would it be possible to have promote_mode as a no-op (leave
SImode values as SImode in the RTL), but have TARGET_PROMOTE_FUNCTION_MODE
perform promotions similar to our current PROMOTE_MODE definition i.e. is
TARGET_PROMOTE_FUNCTION_MODE the hook that is used to canonicalise values
*before* calls and *before* returns?
I’ll do some reading…
I was also curious about benchmarking the alternate ABI choice that leaves the
upper bits undefined, and does narrowing in the caller. It would be an ABI
break so is a no go, but I was curious about the performance of this option.
Any 32-bit ops causes narrowing on demand. It’s only the logical ops that would
need to be explicitly narrowed in this alternate ABI. In any case I don’t think
the RISC-V maintainers would accept an ABI break however i’m curious as to the
advantages and disadvantages of ABIs that do and don’t define the upper bits
for narrower modes when passing values to and from functions.
Thanks,
Michael.
