This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: long long / long long



On Tue, 11 Sep 2001, Jan Hubicka wrote:
>
> 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.

That sounds good.

There are probably many tree-level optimizations that _should_ work on a
"single register" level (it gets really hard to do some simple
optimizations after the split), so it sounds eminently sensible to wait
for the intermediate tree form and do the split after that phase.

> This kills posibility of using SSE/i387 registers for 64bit integer operations
> that is unfortunate too...

I don't think it "kills" it. It just means that the SSE conversion should
(if appropriate) be done at a tree level - which I think is the right
thing anyway. There is _no_ point in doing SSE conversions on an
operation-by-operation basis - the costs of converting to and from SSE are
too big. So SSE conversion should be done at a higher level, so that you
either do _all_ operations in a chain in SSE, or you do none.

> 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.

Absolutely. I think splitting the 64-bit ops up fairly early (ie after
high-level tree optimizations, but long before any low-level RTL has been
worked on) is the only way to get sane code generation on 32-bit hosts.

Of course, one potentially valid approach is to just say "32-bit targets
are going away", but historically it has taken a _looong_ time for new
architectures to get dominant (in fact, historically they never _did_
become dominant at all ;), and I suspect that some day gcc will want to
have at least the option to make "long long" be 128 bits on 64-bit hosts.

In which case having the split infrastructure will be useful even in the
long run.

		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]