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 Mon, 10 Sep 2001 21:45:10 +0200 (MET DST) Michael Matz wrote:
>
> Hi,
>
> 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 ;-|
> 

Hi
in my thesis at university i have done something like this. I called it
"REGSET" 
(SET of REGisters) instead of MREG but it sounds the same.
In the .md i added the "movblk" patterns like this

(define_expand "movblk"
[(set (match_operand:BLK 0 "general_operand" "") 
       (match_operand:BLK 1 "general_operand" ""))]
....

(define_insn "hard_movblk_to_regset"
[(set (match_operand:BLK 0 "regset_operand" "") 
      (match_operand:BLK 1 "memory_operand" "m"))]
....

(define_insn "hard_movblk_from_regset"
[(set (match_operand:BLK 0 "memory_operand" "m") 
       (match_operand:BLK 1 "regset_operand" ""))]
....

Maybe a little primitive but effective.
I also posted a first patch, but not in the *standard* way and not for
the last release.
Hope to have time to do that soon.
Anyhow many changes in the gcc code were necessary, sometimes a little
hard! ;)
I did not implement attributes or other to specify consecutiveness of
registers,
neither asm constraints to use with global register variables.
The idea came out to solve memory access of big structures, because our
machine had lots of registers
(512 per processor!).
My comment is: it is possible, not so difficult, you should agree on the
syntax and the exact behaviour.

ciao
benedetto



> 
> Ciao,
> Michael.


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