https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Resolution|INVALID |---
Status|RESOLVED |SUSPENDED
Last reconfirmed| |2023-01-09
--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
It's not really invalid, but it won't happen any time soon.
The upper bits *are* defined for argument passing, in all our 64-bit ABIs:
for signed type (like here the value is passed sign-extended. But the code
has "(a & b) > 0" which does the comparison as an int. In combine we get
Trying 11 -> 14:
11: r124:SI=r129:DI#4&r130:DI#4
REG_DEAD r130:DI
REG_DEAD r129:DI
14: r125:CC=cmp(r124:SI,0)
REG_DEAD r124:SI
Failed to match this instruction:
(set (reg:CC 125)
(compare:CC (and:SI (subreg:SI (reg:DI 129) 4)
(subreg:SI (reg:DI 130) 4))
(const_int 0 [0])))
If we upgraded some stuff to DImode instead of SImode, sometimes we can
make better code, like we could here. But in other cases the opposite is
true. I think it is likely it helps more often than it would hurt, and we
can upgrade the mode only sometimes as well of course.
In any case, this is just a special case of a much more generic problem
(in all ports, not just rs6000!), that has been known for a very long time,
and no real progress has been made yet. But it definitely should be doable.
To simplify the problem a lot it probably is okay to only consider upgrading
the mode of a pseudo everywhere (so not do it in some insns but not others),
and then assign a score to it. Probably a higher score inside loops, that
is the case where we see this most / where we see it as a shortcoming most.
Where rs6000 is special here is that we have "w" and "d" (32-bit and 64-bit)
variants of many insns (but no smaller versions most of the time fwiw).
