This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: long long / long long
> If gcc developers start looking at double-integer 64-bit things, the
> highest priority by far should be making the _simple_ operations and the
> spilling faster. The code generated for many simple 64-bit ops is
> horrible because gcc has a very strict notion of what a 64-bit entity is
> on a 32-bit architecture. And that notion doesn't always make much
> sense.
>
> For example, gcc seems to be unable to think of a 64-bit entity as two
> almost-independent 32-bit parts, and does some strange register
> allocation (I _think_ gcc can't mix and match registers - it seems to
> always use fixed pairings (ie eax:edx and ecx:ebx).
Actually the problem is that internall GCC represent whole 64bit quantity
as single register. This means that register allocator will assign it
two constuctive 32bit registers.
This is big problem to avoid with current design, but if Jeff's midlevel
RTL takes it's place, I believe we can win by simply splitting the 64bit
quantities early and represent them as two 32bit registers in the lowlevel
RTL chain.
This kills posibility of using SSE/i387 registers for 64bit integer operations
that is unfortunate too...
I don't see other sensible solution to the problem. Even if we teach
register allocation, that the 32bit registers don't have to be consetuctive
still we will load unneded parts of 64bit values to registers etc. etc.
Honza