On 6/19/23 22:52, Tamar Christina wrote:
It's a bit hackish, but could we reject the stack pointer for operand1 in the
stack-tie? And if we do so, does it help?
Yeah this one I had to defer until later this week to look at closer because
what I'm
wondering about is whether the optimization should apply to frame related
RTX as well.
Looking at the description of RTX_FRAME_RELATED_P that this optimization may
end up de-optimizing RISC targets by creating an offset that is larger than
offset
which can be used from a SP making reload having to spill. i.e. sometimes the
move was explicitly done. So perhaps it should not apply it to
RTX_FRAME_RELATED_P in find_oldest_value_reg and copyprop_hardreg_forward_1?
Other parts of this pass already seems to bail out in similar situations. So
I needed to
write some testcases to check what would happen in these cases hence the
deferral.
to later in the week.
Rejecting for RTX_FRAME_RELATED_P would seem reasonable and probably
better in general to me. The cases where we're looking to clean things
up aren't really in the prologue/epilogue, but instead in the main body
after register elimination has turned fp into sp + offset, thus making
all kinds of things no longer valid.
jeff
