On 9/7/2022 8:40 AM, Robin Dapp via Gcc-patches wrote:
Hi,
I recently looked into a sequence like
vzero %v0
vlr %v2, %v0
vlr %v3, %v0.
Ideally we would like to use vzero for all of these sets in order to not
create dependencies.
For some instances of this problem I found the offending snippet to be
the postreload cse pass. If there is a non hard reg whose value is
equivalent to an existing hard reg, it will replace the non hard reg.
The costs are only compared if the respective operand is a CONST_INT_P,
otherwise we always replace.
The comment before says:
/* See if REGNO fits this alternative, and set it up as the
replacement register if we don't have one for this
alternative yet and the operand being replaced is not
a cheap CONST_INT. */
Now, in my case we have a CONST_VECTOR consisting of CONST_INTS (zeros).
This is obviously no CONST_INT therefore the substitution takes place
resulting in a "vlr" instead of a "vzero".
Would it not make sense to always compare costs here? Some backends have
instructions for loading vector constants and there could also be
backends able to load floating point constants directly.
For my snippet getting rid of the CONST_INT check suffices because the
costs are similar and no replacement happens. Was this originally a
shortcut for performance reasons? I thought we were not checking that
many alternatives and only locally at this point anymore.
Any comments or ideas?
It looks sensible to me. ISTM this should be driven by costs, not by
any particular rtx codes. Your patch takes things in the right direction.
Did you did any archeology into this code to see if there was any
history that might shed light on why it doesn't just using the costing
models?
jeff