On 2/2/24 15:48, Greg McGary wrote:
On 2/1/24 10:24 PM, Jeff Law wrote:
On 2/1/24 18:24, Greg McGary wrote:
However, for a machine where (WORD_REGISTER_OPERATIONS &&
load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM
is only known at runtime as 0s or 1s. That's the downstream bug. The
fix for such machines is either (A) forbid static evaluation of the
high part of a PSoM, or (B) forbid transforming (SIGN_EXTEND (MEM
...) ) into a PSoM. My patch does B. Perhaps you prefer A? The
trouble with A is that in the zero-extend case, it is valid to
statically evaluate as 0. It is only the sign-extend case that isn't
known until runtime. By the time we have a PSoM, its upstream
ancestor as sign- or zero-extend is already lost.
Does that give you the understanding you desire, or are there deeper
mysteries to probe?
It's a good start and I can see what you're trying to do -- and it may
in fact be correct -- the quick discussion with Palmer Tuesday and
your follow-up have helped a lot).
But just to be sure, what's the incoming rtl at function entry? just
"debug_rtx (x)" should be sufficient.
input: (sign_extend:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86]
<var_decl 0x7ffff761cb40 minus_1>) [1 minus_1+0 S4 A32]))
result: (subreg:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86]
<var_decl 0x7ffff761cb40 minus_1>) [1 minus_1+0 S4 A32]) 0)
Later, the high part of the PSoM statically evaluates to 0, the code to
load and test is elided, and the incorrect alternative is emitted
unconditionally.
So I think we need to know where that high part gets statically turned
into a zero.
I'm not happy with the sign_extend->subreg transformation as we
generally want to avoid (subreg (mem)) for various reasons. So we'll
probably want to do something like your patch as well. But let's chase
down the static evaluation of the high part to zero first -- that's
clearly wrong given the defined semantics of (subreg (mem)) in the
presence of LOAD_EXTEND_OP.
jeff
