Re: [PATCH] RISC-V: Optimize zbb ins sext.b and sext.h in rv64

[Jeff Law <jeffreyalaw@gmail.com>]

On 3/23/23 20:45, juzhe.zhong@rivai.ai wrote:
> Sounds like you are looking at redundant extension problem in RISC-V port.
> This is the issue I want to fix but I don't find the time to do that.
> My first impression is that we need to fix redundant extension in "ree" 
> PASS.
> I am not sure.
It's actually quite a bit more complicated.

Some extension elimination can and probably should be happening in 
gimple. In gimple you have access to type information as well as range 
information.  So you have the opportunity to do things like rewrite the 
IL to use different types when it's safe to do so, or to use range 
information to identify when an object is already properly extended and 
thus eliminate the extension before we expand gimple into RTL.

Once in RTL, you can use forward propagation to eliminate extensions, or 
at least fold them into existing operations.  combine can eliminate 
extensions and it has the ability to track (for example) if the upper 
bits are copies of the sign bit, if they're known zero, etc.  combine is 
also capable of recognizing that a load implicitly extends and using 
that knowledge to eliminate extensions or to discover that a pair of 
shifts are just zero or sign extending a value, etc etc.  combine also 
interacts with simplify-rtx which is used by other passes, so there's a 
chance that work in simplify-rtx can eliminate extensions not just in 
combine, but in other passes as well.

REE is a post-register allocation pass and kind of the last chance to 
eliminate extensions.

So for any given redundant extension, the way to go (IMHO) is to walk 
through the optimizer pipeline to see where it can potentially be 
eliminated.  In general, the earlier in the optimizer pipeline the 
extension can be eliminated, the better.

Jeff