http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350
davem at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed| |2012-11-06
Ever Confirmed|0 |1
--- Comment #1 from davem at gcc dot gnu.org 2012-11-06 04:23:51 UTC ---
The problem is that the compiler is very constrained about how it
can or cannot use 64-bit operations in 32-bit v9 mode.
When we do use 64-bit instructions, we do so in a very hackish
way in 32-bit mode. We first allocate a "safe" 64-bit register
(the OS only guarentees that %o0-%o7 and %g1-%g7 integer
registers will have their full 64-bits saved if a trap or
context switch occurs) and then we construct the 64-bit value
from the 2 32-bit source operand pieces of each 64-bit input.
Then we decompose the 64-bit "safe" register back into the
32-bit components of the output.
We have some tricks and a very simplistic data flow analyzer
that allows avoiding some aspects of the above work.
This is suboptimal, but what it means is that by the time we do
moves, we have the 64-bit values in 32-bit component registers,
so stx/ldx isn't really an option.
The basic issue is that it's an enormous task exposing to the
compiler that we really can do full 64-bit operations in these
registers. That is a huge amount of delicate work, and therefore
this is really a feature request rather than a bug report, so I'm
closing this.
