SMALL_REGISTER_CLASSES

SMALL_REGISTER_CLASSES

[Michael P. Hayes]

Looking through the GCC code I get the impression that
SMALL_REGISTER_CLASSES has been used to infer that a target has only a
few registers, rather than its original meaning, where it signified
that registers explicity mentioned in the RTL had to be used as spill
registers.

With SMALL_REGISTER_CLASSES set, the combiner won't combine insn 4 with
insn 12.  Is there a good reason for this?


(insn 4 2 6 (set (reg/v:QI 36)
        (reg:QI 10 ar2)) 5 {movqi_noclobber} (nil)
    (expr_list:REG_DEAD (reg:QI 10 ar2)
        (nil)))

(insn 6 4 7 (set (reg/v:QI 37)
        (reg:QI 2 r2)) 5 {movqi_noclobber} (nil)
    (expr_list:REG_DEAD (reg:QI 2 r2)
        (nil)))

(insn 12 10 14 (set (reg:QI 39)
        (mem/s:QI (plus:QI (reg/v:QI 36)
                (const_int 5)))) 5 {movqi_noclobber} (insn_list 4 (nil))
    (expr_list:REG_DEAD (reg/v:QI 36)
        (nil)))

Michael.

Re: SMALL_REGISTER_CLASSES

[amylaar]

> Looking through the GCC code I get the impression that
> SMALL_REGISTER_CLASSES has been used to infer that a target has only a
> few registers, rather than its original meaning, where it signified
> that registers explicity mentioned in the RTL had to be used as spill
> registers.
> 
> With SMALL_REGISTER_CLASSES set, the combiner won't combine insn 4 with
> insn 12.  Is there a good reason for this?

Yes. (reg:QI 10 ar2) is a hard register (at least as far as the compiler
is concerned).  If insn 4 was combined into insn 12, the life of ar2
would be lengthened, thus creating possible conflicts with reloads for
insn 6 that use that register.
If such reloads can actually be created is immaterial; what counts is
that the combiner knows - or doesn't know - that no such reloads are
possible.
SMALL_REGISTER_CLASSES gives reload the license to use registers that
are explicitly mentioned in the rtl.
> 
> 
> (insn 4 2 6 (set (reg/v:QI 36)
>         (reg:QI 10 ar2)) 5 {movqi_noclobber} (nil)
>     (expr_list:REG_DEAD (reg:QI 10 ar2)
>         (nil)))
> 
> (insn 6 4 7 (set (reg/v:QI 37)
>         (reg:QI 2 r2)) 5 {movqi_noclobber} (nil)
>     (expr_list:REG_DEAD (reg:QI 2 r2)
>         (nil)))
> 
> (insn 12 10 14 (set (reg:QI 39)
>         (mem/s:QI (plus:QI (reg/v:QI 36)
>                 (const_int 5)))) 5 {movqi_noclobber} (insn_list 4 (nil))
>     (expr_list:REG_DEAD (reg/v:QI 36)
>         (nil)))

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 199801200202.PAA11726@ongaonga.chch.cri.nz >you write:
  > 
  > Looking through the GCC code I get the impression that
  > SMALL_REGISTER_CLASSES has been used to infer that a target has only a
  > few registers, rather than its original meaning, where it signified
  > that registers explicity mentioned in the RTL had to be used as spill
  > registers.
No, it still means those registers need to be used as spills, it just happens
that machines with few registers tend to also have registers which are
explicitly mentioned in RTL and must still be able to use them as spills.

The combination doesn't take place because you'd be extending the lifetime
of a hard register.  You want to avoid doing that at all costs when
SMALL_REGISTER_CLASSES is true.

jeff

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 199801202139.KAA13941@ongaonga.chch.cri.nz >you write:
  > Jeffrey A Law writes:
  > The problem I'm having is that while I have many registers, there is
  > one rarely used class that is composed entirely of registers that
  > are explicitly mentioned in the RTL.
Yup.  I understand this problem completely since it came up on the
PA port (there's two register classes which have a single register,
but the other register classes have tons of registers).

Instead of defining SMALL_REGISTER_CLASSES, we came up with
CLASS_LIKELY_SPILLED_P which might be more useful to you.


  > I'm loathe to have to define SMALL_REGISTER_CLASSES in general since
  > it stomps on many optimisations, but I have a rare case where reload
  > has to spill one of the registers mentioned in the RTL.  From what
  > I've noticed, reload can safely do it, but it won't without
  > SMALL_REGISTER_CLASSES defined.
Right.  Any chance you could rework things so that reload doesn't have
to spill the register.  Or avoid mentioning those regs explicitly in RTL
(which we ended up doing on the PA for %r1 and %sar).

  > I suggested to J"orn that SMALL_REGISTER_CLASSES requires a hard regno
  > argument.  J'orn (amylaar@cygnus.co.uk) wrote:
I suggested this myself a few years back :-)  Such a chance would certainly
be interesting.

But I would recommend first looking into other solutions first, mentioning
regs explicitly in RTL is a bad thing

Jeff

Re: SMALL_REGISTER_CLASSES

[Michael P. Hayes]

Jeffrey A Law writes:
 >   In message < 199801200202.PAA11726@ongaonga.chch.cri.nz >you write:
 >   > 
 >   > Looking through the GCC code I get the impression that
 >   > SMALL_REGISTER_CLASSES has been used to infer that a target has only a
 >   > few registers, rather than its original meaning, where it signified
 >   > that registers explicity mentioned in the RTL had to be used as spill
 >   > registers.
 > No, it still means those registers need to be used as spills, it just happens
 > that machines with few registers tend to also have registers which are
 > explicitly mentioned in RTL and must still be able to use them as spills.

The problem I'm having is that while I have many registers, there is
one rarely used class that is composed entirely of registers that
are explicitly mentioned in the RTL.

I'm loathe to have to define SMALL_REGISTER_CLASSES in general since
it stomps on many optimisations, but I have a rare case where reload
has to spill one of the registers mentioned in the RTL.  From what
I've noticed, reload can safely do it, but it won't without
SMALL_REGISTER_CLASSES defined.

I suggested to J"orn that SMALL_REGISTER_CLASSES requires a hard regno
argument.  J'orn (amylaar@cygnus.co.uk) wrote:

  That would be a quiet substantial change, but I see that some more
  differentiation could make sense.  However, rather than a regno, I suggest
  to use a register class as an argument. This way, when register allocation /
  reload wants to know about a particular register class, it can get at this
  information easily.  If you want to know about a particular register,
  you'd use SMALL_REGISTER_CLASSES (REGNO_REG_CLASS (regno)).

Most of the time SMALL_REGISTER_CLASSES is used when there is also a
test to see if regno is a hard register, so I thought that it could be
combined in the macro.  Besides, this macro shouldn't need to be
defined by each target, since the condition is computable.

Re: SMALL_REGISTER_CLASSES

[Michael P. Hayes]

Jeffrey A Law writes:
 > 
 >   In message < 199801202139.KAA13941@ongaonga.chch.cri.nz >you write:
 >   > Jeffrey A Law writes:
 >   > The problem I'm having is that while I have many registers, there is
 >   > one rarely used class that is composed entirely of registers that
 >   > are explicitly mentioned in the RTL.

 > Instead of defining SMALL_REGISTER_CLASSES, we came up with
 > CLASS_LIKELY_SPILLED_P which might be more useful to you.

Yeah, I'm using that as well to keep reload happy for another problem
class I have :-(

 > Right.  Any chance you could rework things so that reload doesn't have
 > to spill the register.  Or avoid mentioning those regs explicitly in RTL
 > (which we ended up doing on the PA for %r1 and %sar).

The class I'm having fun with has four registers, but they are all
either incoming function argument or function return registers.

So far I've managed to get away with not defining
SMALL_REGISTER_CLASSES and modifying order_regs_for_reload to not
include the explicitly mentioned registers in bad_spill_regs.
However, I imagine that I'll get shot in the foot one day....

Michael.

Re: SMALL_REGISTER_CLASSES

[Michael P. Hayes]

Jeffrey A Law writes:
 >   > The class I'm having fun with has four registers, but they are all
 >   > either incoming function argument or function return registers.
 > Ouch.  Yup.  Either you need to find a way to never spill them, or you're
 > going to have to go down the SMALL_REGISTER_CLASSES route at some point.

My ignorance of the former is driving me reluctantly toward the latter :-(
That's why I'm keen for a less brutal form of SMALL_REGISTER_CLASSES
that decides on a per register or register class basis...


Michael

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 199801202236.LAA14168@ongaonga.chch.cri.nz >you write:
  >  > CLASS_LIKELY_SPILLED_P which might be more useful to you.
  > 
  > Yeah, I'm using that as well to keep reload happy for another problem
  > class I have :-(
Yup.  

  >  > Right.  Any chance you could rework things so that reload doesn't have
  >  > to spill the register.  Or avoid mentioning those regs explicitly in RTL
  >  > (which we ended up doing on the PA for %r1 and %sar).
  > 
  > The class I'm having fun with has four registers, but they are all
  > either incoming function argument or function return registers.
Ouch.  Yup.  Either you need to find a way to never spill them, or you're
going to have to go down the SMALL_REGISTER_CLASSES route at some point.

  > So far I've managed to get away with not defining
  > SMALL_REGISTER_CLASSES and modifying order_regs_for_reload to not
  > include the explicitly mentioned registers in bad_spill_regs.
  > However, I imagine that I'll get shot in the foot one day....
Well, that's basically what SMALL_REGISTER_CLASSES does at some point
in reload -- it takes explicitly mentioned registers out of bad_spill_regs.

I suspect you will need to define SMALL_REGISTER_CLASSES at some point
though -- the way you're doing things now will end up causing trouble
at some point.

jeff

Re: SMALL_REGISTER_CLASSES

[Jan Hubicka]

> No problem.  There's a lot of terminology we tend to use.  It takes a long
> time to learn all of them.  There's no way you could have known.
Thanks for the patience :)
> 
>   > 
>   > > This is not strictly a scheduler bug since no data dependency exists betw
>   > een
>   > 
>   > As I described, I believe scheduer ought to handle hard registers with
>   > SMALL_REGISTER_CLASSES as special case like many of other optimization does
> I don't think this should be the scheduler's responsibility.  If we are going
> to avoid such code motions, then parts of the compiler which compute data
> dependencies need to add a dependence between explicit uses of a register and
> uses via pseudos which can only be allocated to a single register.
huh. I agree, that much better is to remove S_R_C than fix it, but I still not
understand why scheduler behaviour is correct in S_R_C sense. Whats the exactly
definition of register lifetime? I interpret is as number of insns between first
and last use of register. In this sense rule "with S_R_C you can't extend hard register
lifetime" I interpret as "you can not put any new insns between two insns using hard
register". So I think scheduler is not alowed to put any insns between two 
insns using hard register so it is not dependent at register dependencies. Only
implementation I see is to make artificial basic block boundary there and
prohibit interblock scheduling...

Just curious...
>   > Sounds great. I tought that design decision is that reload will not spill
>   > hard register. So you mean that in future reload should do that?
> Yes.  Long term, I would like to see reload be able to handle these situations.
> 
> S_R_C is a hack.  It is a disgusting hack.  It is a disgusting hack to work
> around our lame register allocators & reloading pass.  It is a disgusting
> hack that needs to be eliminated rather than propagated.
100% agreed...
> 
> 
>   >  Or that
>   > LCM (or something else) will be able to move divmod outside the eax
>   > lifetime and solve this problem just by reordering code?
> No.  That's not the point of LCM.  LCM may hide some of these problems, but
> it would be by accident, not by design.  LCM is an algorithm to improve
> optimizations, not fix bugs.  Relying on it to hide these kinds of problems
> would be a mistake.
What I was thinking about is the sequence like this:
call_insn
<code>
(set (pseudo) (returned_hard_reg))

(this is situation where divmod pattern is in <code>)

if code clobbers returned_hard_reg (using constraints, not explicitly), even reload
working correctly with hard regs must spill it away hard_reg and then spill back
resulting in two unnecesary moves.  I think thats place for LCM :)

Honza
> 
> jeff

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 19981202154558.64153@atrey.karlin.mff.cuni.cz >you write:
  > huh. I agree, that much better is to remove S_R_C than fix it, but I still 
  > not understand why scheduler behaviour is correct in S_R_C sense.
The only things which can/should inhibit scheduler movement are
DATA DEPENDENCIES.  Period.  It is not, shall not and will not be the
scheduler's responsibility to worry about S_R_C.




  > Only
  > implementation I see is to make artificial basic block boundary there and
  > prohibit interblock scheduling...
No.  if you want to prevent the motion, you have to add a data dependency,
other schemes are simply wrong.

jeff

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 19981201130940.53502@atrey.karlin.mff.cuni.cz >you write:
  > > Those patterns do not explicitly use eax.  At least using the usual defin
  > ition
  > > of "explicitly using ..." in the gcc world.
  > 
  > I understand to this. Sorry for another inexact formulation :(.
No problem.  There's a lot of terminology we tend to use.  It takes a long
time to learn all of them.  There's no way you could have known.

  > I believe that goal of SMALL_REIGSTER_CLASSES is to prohibit extending
  > the lifetime of hard register. So I think that scheduler is not alowed to
  > put new insns between hard register setter and user, because it will extend
  > lifetime of that register by one.
  > 
  > This is according to old documentation about SMALL_REGISTER_CLASSES and
  > it was changed recently, so I am probably wrong.
  > 
  > Whats about other SMALL_REGISTER_CLASSES architectures. Is scheduler unsafe
  > there too?
In large part, scheduling before reload on a SMALL_REGISTER_CLASSES machine is
considered unsafe.  This is one of the problems that will have to be solved to
make scheduling before allocation safe on a SMALL_REGISTER_CLASSES machine.

In general, we need to be moving away from S_R_C code.  This means fixing the
reload issues, not adding more hacks to disable code elsewhere in the compiler
to make S_R_C machines happy.

  > 
  > > This is not strictly a scheduler bug since no data dependency exists betw
  > een
  > 
  > As I described, I believe scheduer ought to handle hard registers with
  > SMALL_REGISTER_CLASSES as special case like many of other optimization does
I don't think this should be the scheduler's responsibility.  If we are going
to avoid such code motions, then parts of the compiler which compute data
dependencies need to add a dependence between explicit uses of a register and
uses via pseudos which can only be allocated to a single register.


  > (If we want to have SMALL_REGISTER_CLASSES working correctly. Maybe it is
  > not so significant as work on removing them.)
We want to get rid of S_R_C, not have it bleed elsewhere in the compiler.

  > Sounds great. I tought that design decision is that reload will not spill
  > hard register. So you mean that in future reload should do that?
Yes.  Long term, I would like to see reload be able to handle these situations.

S_R_C is a hack.  It is a disgusting hack.  It is a disgusting hack to work
around our lame register allocators & reloading pass.  It is a disgusting
hack that needs to be eliminated rather than propagated.


  >  Or that
  > LCM (or something else) will be able to move divmod outside the eax
  > lifetime and solve this problem just by reordering code?
No.  That's not the point of LCM.  LCM may hide some of these problems, but
it would be by accident, not by design.  LCM is an algorithm to improve
optimizations, not fix bugs.  Relying on it to hide these kinds of problems
would be a mistake.

jeff

Re: SMALL_REGISTER_CLASSES

[Jan Hubicka]

> Those patterns do not explicitly use eax.  At least using the usual definition
> of "explicitly using ..." in the gcc world.

I understand to this. Sorry for another inexact formulation :(.

> Schedulers use data dependency to avoid incorrect code motions.  There is no
> data dependency between these insns.

I believe that goal of SMALL_REIGSTER_CLASSES is to prohibit extending
the lifetime of hard register. So I think that scheduler is not alowed to put
new insns between hard register setter and user, because it will extend
lifetime of that register by one.

This is according to old documentation about SMALL_REGISTER_CLASSES and
it was changed recently, so I am probably wrong.

Whats about other SMALL_REGISTER_CLASSES architectures. Is scheduler unsafe
there too?

> This is not strictly a scheduler bug since no data dependency exists between

As I described, I believe scheduer ought to handle hard registers with
SMALL_REGISTER_CLASSES as special case like many of other optimization does.
(If we want to have SMALL_REGISTER_CLASSES working correctly. Maybe it is
not so significant as work on removing them.)

> those insns.  However, IMHO, reload should be able to deal with this problem
> (long term).  Until it does enabling the sched1 for the x86 port is unsafe.

Sounds great. I tought that design decision is that reload will not spill
hard register. So you mean that in future reload should do that? Or that
LCM (or something else) will be able to move divmod outside the eax
lifetime and solve this problem just by reordering code?
> 
>   > One of solution should be to change all patterns using registers explicitly
>   > to expands in call style (so do something like that:)
>   > (set (reg eax) (operand))
>   > (div (reg eax) (operand2))
> No.  Do not do this.  Using registers like that is considered extremely bad
> form.
OK.
> 
>   > 
>   > Other solution that comes into mind is to let reload spill explicitly used 
>   > registers,
> This is probably the long term solution.
OK. So I can just wait to get thinks solved :)

Honza
> 
> jeff

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message <19981129162344.04480@atrey.karlin.mff.cuni.cz>you write:
  > Well, I am not expert, but I don't think it will work. I believe that insns
  > explicitly using eax register (divmod patterns) will cause lots of troubles
Those patterns do not explicitly use eax.  At least using the usual definition
of "explicitly using ..." in the gcc world.

They reference a register via register_operand which has a constraint which
forces the use of eax later in the compiler.  But until register assignments
are made, the divmod pattern uses pseudo regs.

If the patterns instead used  (reg:SI 0), that would be an explicit use of 
eax.


  > I am getting them even with SMALL_REGISTER_CLASSES enabled (and with my pat
  > ch).
  > Compiler quite often crases in cases where function is called, division
  > is done later, haifa is enabled and my scheduling patch is active.
  > 
  > Insns from code are approx folowing:
  > call_function
  > mov eax, register_for_returned_value
  > divmod (use eax)
  > 
  > in case this is done in one basic block (function must have const attribute
  >  I believe)
  > haifa moves divmod between call and mov and that makes reload crashing (it 
  > can't spill
  > eax register, because it is explicitly used).
  > 
  > This sounds to me like haifa is not SMALL_REGISTER_CLASSES conforming. 
  > Haifa don't seems to contain any code to handle SMALL_REGISTER_CLASSES corr
  > ectly.
Schedulers use data dependency to avoid incorrect code motions.  There is no
data dependency between these insns.

This kind of situation is precisely why using scheduling before allocation on
the x86 is unsafe.

This is not strictly a scheduler bug since no data dependency exists between
those insns.  However, IMHO, reload should be able to deal with this problem
(long term).  Until it does enabling the sched1 for the x86 port is unsafe.

  > One of solution should be to change all patterns using registers explicitly
  > to expands in call style (so do something like that:)
  > (set (reg eax) (operand))
  > (div (reg eax) (operand2))
No.  Do not do this.  Using registers like that is considered extremely bad
form.

  > 
  > Other solution that comes into mind is to let reload spill explicitly used 
  > registers,
This is probably the long term solution.

jeff

Re: SMALL_REGISTER_CLASSES

[Jan Hubicka]

> > Date: Mon, 23 Nov 1998 22:58:32 -0700
> > From: Jeffrey A Law <law@cygnus.com>
> 
> > > With Bernd's changes to reload, is SMALL_REGISTER_CLASSES required,
> >
> > I suspect it is no longer required.
> 
> > In fact, one of my todos is to remove the SMALL_REGISTER_CLASSES
> > define for the mn102 and mn103 ports and see what happens :-)
> 
> Since x86 defines it, and since we have a bizzilion people with x86,
> would it make sense for people to try it out on x86 and inspect code
> differences and do performace reviews on the various code they have?!

Well, I am not expert, but I don't think it will work. I believe that insns
explicitly using eax register (divmod patterns) will cause lots of troubles.
I am getting them even with SMALL_REGISTER_CLASSES enabled (and with my patch).
Compiler quite often crases in cases where function is called, division
is done later, haifa is enabled and my scheduling patch is active.

Insns from code are approx folowing:
call_function
mov eax, register_for_returned_value
divmod (use eax)

in case this is done in one basic block (function must have const attribute I believe)
haifa moves divmod between call and mov and that makes reload crashing (it can't spill
eax register, because it is explicitly used).

This sounds to me like haifa is not SMALL_REGISTER_CLASSES conforming. 
Haifa don't seems to contain any code to handle SMALL_REGISTER_CLASSES correctly.

Similar problems will be much more common if you undefine it, so I believe compiler
will not bootstrap.


One of solution should be to change all patterns using registers explicitly
to expands in call style (so do something like that:)
(set (reg eax) (operand))
(div (reg eax) (operand2))
this should prevent compiler from mixing such insns. I don't know how bad effects
it should have to generated code, but I believe that alpha is using
it happily for its div patterns.

But this IMO just moves problem to cases where insn accepts one of the two registers
and both registers are explicitly used. Similar case should happend for all registers
too.

Other solution that comes into mind is to let reload spill explicitly used registers,
but it should break some gcc design invariant and result in suboptimal code
(moving returned value to other register, then back to eax and then to right register)

Last solution I was thinking about is to prohibit using hard registers in i386.md at all.
But this seems to be quite hard to implement, because gcc expect functions to be returing
values in hard registers....


Honza
-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: SMALL_REGISTER_CLASSES

[Mike Stump]

> Date: Wed, 25 Nov 1998 08:08:29 -0800
> From: mrs@wrs.com (Mike Stump)
> To: law@cygnus.com, m.hayes@elec.canterbury.ac.nz
> Cc: egcs@cygnus.com

> > Date: Mon, 23 Nov 1998 22:58:32 -0700
> > From: Jeffrey A Law <law@cygnus.com>

> > > With Bernd's changes to reload, is SMALL_REGISTER_CLASSES required,
> >
> > I suspect it is no longer required.

Ok, I took my own advice, and tried it on x86:

stage1/xgcc -Bstage1/ -B/usr/local/egcs-981110/i586-pc-linux-gnulibc1/bin/ -c  -DIN_GCC   -DUSE_GNULIBC_1 -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H     -I. -I../../egcs/gcc -I../../egcs/gcc/config -I../../egcs/gcc/../include ../../egcs/gcc/c-aux-info.c
../../egcs/gcc/cccp.c: In function `rescan':
../../egcs/gcc/cccp.c:2616: warning: `c' might be used uninitialized in this function
../../egcs/gcc/c-aux-info.c: In function `gen_type':
../../egcs/gcc/c-aux-info.c:509: fixed or forbidden register 0 (ax) was spilled for class AREG.
../../egcs/gcc/c-aux-info.c:509: This may be due to a compiler bug or to impossible asm
../../egcs/gcc/c-aux-info.c:509: statements or clauses.
../../egcs/gcc/c-aux-info.c:509: This is the instruction:
(insn 248 247 251 (parallel[ 
            (set (reg:SI 0 %eax)
                (div:SI (reg:SI 3 %ebx)
                    (reg:SI 0 %eax)))
            (set (reg:SI 1 %edx)
                (mod:SI (reg:SI 3 %ebx)
                    (reg:SI 0 %eax)))
        ] ) 184 {divmodsi4} (insn_list 245 (insn_list 240 (nil)))
    (expr_list:REG_DEAD (reg:SI 0 %eax)
        (expr_list:REG_UNUSED (reg:SI 1 %edx)
            (expr_list:REG_DEAD (reg:SI 3 %ebx)
                (nil)))))
../../egcs/gcc/toplev.c:1395: Internal compiler error in function fatal_insn
make[2]: *** [c-aux-info.o] Error 1

So, no, we aren't there yet...  and the define is still necessary.

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 199811251608.IAA28589@kankakee.wrs.com >you write:
  > > Date: Mon, 23 Nov 1998 22:58:32 -0700
  > > From: Jeffrey A Law <law@cygnus.com>
  > 
  > > > With Bernd's changes to reload, is SMALL_REGISTER_CLASSES required,
  > >
  > > I suspect it is no longer required.
  > 
  > > In fact, one of my todos is to remove the SMALL_REGISTER_CLASSES
  > > define for the mn102 and mn103 ports and see what happens :-)
  > 
  > Since x86 defines it, and since we have a bizzilion people with x86,
  > would it make sense for people to try it out on x86 and inspect code
  > differences and do performace reviews on the various code they have?!
Interestingly enough I tried to build a mn102 with SMALL_REGISTER_CLASSES
turned off.  It died.  Sigh...

jeff

Re: SMALL_REGISTER_CLASSES

[Mike Stump]

> Date: Mon, 23 Nov 1998 22:58:32 -0700
> From: Jeffrey A Law <law@cygnus.com>

> > With Bernd's changes to reload, is SMALL_REGISTER_CLASSES required,
>
> I suspect it is no longer required.

> In fact, one of my todos is to remove the SMALL_REGISTER_CLASSES
> define for the mn102 and mn103 ports and see what happens :-)

Since x86 defines it, and since we have a bizzilion people with x86,
would it make sense for people to try it out on x86 and inspect code
differences and do performace reviews on the various code they have?!

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 13913.50996.630498.382978@ongaonga.elec.canterbury.ac.nz >you writ
e:
  > 
  > With Bernd's changes to reload, is SMALL_REGISTER_CLASSES required,
  > the documentation in tm.texi relevant, or none of the above?
  > 
  > If SMALL_REGISTER_CLASSES is still required, can someone state what
  > the necessary conditions are for it to be defined?
I suspect it is no longer required.  However, we need to approach its removal
with some caution.

In fact, one of my todos is to remove the SMALL_REGISTER_CLASSES define for the
mn102 and mn103 ports and see what happens :-)

jeff

SMALL_REGISTER_CLASSES

[Michael Hayes]

With Bernd's changes to reload, is SMALL_REGISTER_CLASSES required,
the documentation in tm.texi relevant, or none of the above?

If SMALL_REGISTER_CLASSES is still required, can someone state what
the necessary conditions are for it to be defined?

Michael.

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 9801262039.AA35348@rios1.watson.ibm.com >you write:
  > 	The MD file can clobber a match_scratch of the single register
  > class but asm statements do not appear to be able to express the same
  > thing.  Geoff Keating and I were wondering if clobbering a specific
  > register in a class containing only that register should not automatically
  > be converted into a match_scratch of that register class?  Is there any
  > reason this is not done or cannot be done?  This or something similar
  > would seem to solve the problem and prevent the GCC spill error.
Interesting.  I can't think of a reason why this couldn't be done, and it
would certainly help (but not completely solve) these problems.

jeff

Re: SMALL_REGISTER_CLASSES

[David Edelsohn]

	GCC asm statements require explicit registers to be specified for
clobbers.  This can cause problems for ports where some of the registers
specified are in small register classes but the SMALL_REGISTER_CLASSES
macro is not defined for the port because the MD file itself does not need
to mention those registers explicitly.  Defining the macro is not an
acceptable option.

	The MD file can clobber a match_scratch of the single register
class but asm statements do not appear to be able to express the same
thing.  Geoff Keating and I were wondering if clobbering a specific
register in a class containing only that register should not automatically
be converted into a match_scratch of that register class?  Is there any
reason this is not done or cannot be done?  This or something similar
would seem to solve the problem and prevent the GCC spill error.

David

Re: SMALL_REGISTER_CLASSES

[amylaar]

> You can't really deal with this using 'x' [for the audience, 'x' is
> the register class that includes only register cr0].  You might want
> to write
> 
> asm ("whatever" : "x"(clobbered));
> 
> but then you have to declare 'clobbered' as a variable, and you can't
> because there isn't a C type which can have MODE_CC :-(.

Hmmm.  Seems like a shortcoming of extended asm to me.  Maybe we should
have a fourth category of operands - scratch operands, giving a constraint
letter (list) and a mode.

Re: SMALL_REGISTER_CLASSES

[Geoffrey KEATING]

> Date: Mon, 26 Jan 1998 00:24:49 -0500
> From: David Edelsohn <dje@watson.ibm.com>

> >>>>> Geoffrey KEATING writes:
> 
> > Unfortunately, the user can mention regs explicitly in 'asm'
> > statements, too.  This causes problems on rs6000, where there are
> > no small register classes mentioned in the RTL, but users can write
> > things like
> 
> > asm ("" : : : "cr0");
> 
> > and get 'forbidden register spilled' if a pseudo (in this case, most
> > likely derived from a "CC" in the RTL) needs a register of that class.
> 
> 	This example can be handled by "x" and "y" register classes,
> right?  Or is this only a problem with asm clobbered registers?

Only with asm.

You can't really deal with this using 'x' [for the audience, 'x' is
the register class that includes only register cr0].  You might want
to write

asm ("whatever" : "x"(clobbered));

but then you have to declare 'clobbered' as a variable, and you can't
because there isn't a C type which can have MODE_CC :-(.

You can see egcs crash by trying

int foo(int x) { asm ("" : : : "cr0"); return x & 123; }

because the RTL for '& 123' needs to find a register in class 'x' (to
clobber it again :-) ).

--
Geoff Keating <Geoff.Keating@anu.edu.au>

Re: SMALL_REGISTER_CLASSES

[David Edelsohn]

>>>>> Geoffrey KEATING writes:

Geoffrey> Unfortunately, the user can mention regs explicitly in 'asm'
Geoffrey> statements, too.  This causes problems on rs6000, where there are
Geoffrey> no small register classes mentioned in the RTL, but users can write
Geoffrey> things like

Geoffrey> asm ("" : : : "cr0");

Geoffrey> and get 'forbidden register spilled' if a pseudo (in this case, most
Geoffrey> likely derived from a "CC" in the RTL) needs a register of that class.

	This example can be handled by "x" and "y" register classes,
right?  Or is this only a problem with asm clobbered registers?

David

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 199801260522.QAA01623@discus.anu.edu.au >you write:
  > > This is a separate and distinct problem from whether or not a machine
  > > description should mention registers explicitly in RTL.
  > 
  > I mean,  you still have to define SMALL_REGISTER_CLASSES (or equivalent)
  > if you have small register classes, whether or not you mention
  > registers in those classes in the RTL.
Not necessarily.

In many cases using these registers by users is just plain not going to work,
so there's no sense in crippling a machine description by defining
SMALL_REGISTER_CLASSES just because a user might use one of these registers
in an asm.



jeff

Re: SMALL_REGISTER_CLASSES

[Geoffrey KEATING]

> Date: Sun, 25 Jan 1998 22:20:11 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

>   In message < 199801260508.QAA01591@discus.anu.edu.au >you write:
>   > Unfortunately, the user can mention regs explicitly in 'asm'
>   > statements, too.  This causes problems on rs6000, where there are
>   > no small register classes mentioned in the RTL, but users can write
>   > things like
>   > 
>   > asm ("" : : : "cr0");
>   > 
>   > and get 'forbidden register spilled' if a pseudo (in this case, most
>   > likely derived from a "CC" in the RTL) needs a register of that class.
> This is a separate and distinct problem from whether or not a machine
> description should mention registers explicitly in RTL.

I mean,  you still have to define SMALL_REGISTER_CLASSES (or equivalent)
if you have small register classes, whether or not you mention
registers in those classes in the RTL.

--
Geoff Keating <Geoff.Keating@anu.edu.au>

Re: SMALL_REGISTER_CLASSES

[Jeffrey A Law]

  In message < 199801260508.QAA01591@discus.anu.edu.au >you write:
  > Unfortunately, the user can mention regs explicitly in 'asm'
  > statements, too.  This causes problems on rs6000, where there are
  > no small register classes mentioned in the RTL, but users can write
  > things like
  > 
  > asm ("" : : : "cr0");
  > 
  > and get 'forbidden register spilled' if a pseudo (in this case, most
  > likely derived from a "CC" in the RTL) needs a register of that class.
This is a separate and distinct problem from whether or not a machine
description should mention registers explicitly in RTL.

Jeff

Re: SMALL_REGISTER_CLASSES

[Geoffrey KEATING]

> But I would recommend first looking into other solutions first, mentioning
> regs explicitly in RTL is a bad thing

Unfortunately, the user can mention regs explicitly in 'asm'
statements, too.  This causes problems on rs6000, where there are
no small register classes mentioned in the RTL, but users can write
things like

asm ("" : : : "cr0");

and get 'forbidden register spilled' if a pseudo (in this case, most
likely derived from a "CC" in the RTL) needs a register of that class.

--
Geoff Keating <Geoff.Keating@anu.edu.au>