http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366
--- Comment #5 from John David Anglin <danglin at gcc dot gnu.org> 2011-04-02
19:56:50 UTC ---
With pa_secondary_reload fixed, the following code is generated at -O0:
subi 63,%r31,%r31
std %r31,80(%r3)
fldd 80(%r3),%fr22
fstd %fr22,80(%r3)
ldd 80(%r3),%r1
mtsar %r1
depdi,z 1,%sar,64,%r31
I don't know why reload generates such bad code. The SAR shift amount
register is a special 5/6 bit register used for shift operations.
It can only be loaded from a general register.
We seem to have an output reload that causes the copy from r31
to fr22. Then fr22 is copied back to general register r1. Then
it is moved to the sar register. Why did reload generate this
code? r31 could have been moved directly. I would have thought
the costs in moving r31 to fr22 and back to r1 would have inhibited
this alternative relative to directly moving r31 to the sar.
