This is the mail archive of the
mailing list for the GCC project.
Re: long long / long long
- To: Bernd Schmidt <bernds at redhat dot com>
- Subject: Re: long long / long long
- From: Michael Matz <matzmich at cs dot tu-berlin dot de>
- Date: Mon, 10 Sep 2001 21:45:10 +0200 (MET DST)
- cc: <gcc at gcc dot gnu dot org>
On Mon, 10 Sep 2001, Bernd Schmidt wrote:
> > Well, the Linux kernel developers found that they couldn't let gcc
> > do long long arithmetic because it did such a poor job, so they do
> > it in assembly or in C on pairs of 32 bit values instead. So at
> > least some folks probably wouldn't mind seeing an improvement.
> The main problem probably is the register allocator's requirement that
> DImode values be allocated to adjacent registers.
Yes, that requirement creates many constraints.
> Unfortunately this is not going to be easy to change.
The sad thing is, that it _is_ easy to change in the allocator, and in
fact would make the algorithm simpler (I'm talking only about the
new-regalloc) and the graph easier colorable. The thing which horrifies
me is the encoding of that requirement in the different machine
descriptions. A first step would be to define a new rtx code MREG
("multi" reg), which can possibly contain a set of (disjoint) REG
or SUBREG expressions, including the then necessary handling of multi-reg
moves (with cycle breaking). The occurences of those MREG rtx's could
probably be limited to few passes around the allocator. Unfortunately
nevertheless all .md files would need a good overhaul. If we only had
such a multi-reg rtx from the beginning ;-|