[PATCH] RISC-V: Synthesize power-of-two constants.

[钟居哲]

Ok. I prefer just keep scalar load + vmv.v.x by default since I believe most machines 
prefer this way.



juzhe.zhong@rivai.ai
 
From: Jeff Law
Date: 2023-05-31 06:09
To: 钟居哲; andrew; rdapp.gcc
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Synthesize power-of-two constants.
 
 
On 5/30/23 16:01, 钟居哲 wrote:
> I agree with Andrew.
> 
> And I don't think this patch is appropriate for following reasons:
> 1. This patch increases vector workload in machine since
>       it convert scalar load + vmv.v.x into vmv.v.i + vsll.vi.
This is probably uarch dependent.  I can probably construct cases where 
the first will be better and I can probably construct cases where the 
latter will be better.  In fact the recommendation from our uarch team 
is to generally do this stuff on the vector side.
 
 
 
> 2. For multi-issue OoO machine, scalar instructions are very cheap
>      when they are located in vector codegen. For example a sequence
>      like this:
>        scalar insn
>        scalar insn
>        vector insn
>        scalar insn
> vector insn
>        ....
>        In such situation, we can issue multiple instructions simultaneously,
>        and the latency of scalar instructions will be hided so scalar 
> instruction
>        is cheap. Wheras this patch increasing vector pipeline workload 
> is not
>        friendly to OoO machine what I mentioned above.
I probably need to be careful what I say here :-)  I'll go with mixing 
vector/scalar code may incur certain penalties on some 
microarchitectures depending on the exact code sequences involved.
 
 
> 3.   I can image the only benefit of this patch is that we can reduce 
> scalar register pressure
>        in some extreme circumstances. However, I don't this benefit is 
> "real" since GCC should
>        well schedule the instruction sequence when we well tune the 
> vector instructions scheduling
>        model and cost model to make such register live range very short 
> when the scalar register
>        pressure is very high.
> 
> Overal, I disagree with this patch.
What I think this all argues is that it'll likely need to be uarch 
dependent.    I'm not yet sure how to describe the properties of the 
uarch in a concise manner to put into our costing structure yet though.
 
jeff