question regarding asm()

question regarding asm()

[Marc Lehmann]

Sorry to post this question again, but my last e-mail was definitely ignored,
and the documentation still is wrong.... (And I still have no idea
how, for example, kernel people are supposed to tell gcc NOT to
use some registers in an asm that are used in an asm...)

----- Forwarded message from Marc Lehmann -----

David Edelsohn wrote:
>	Clobber just means that GCC cannot make assumptions about the
>register after the call, not before.

That's what I expected, but the docs seems to sugest otherwise..

>You explicitly use r9 and r10 in your pattern but never tell GCC.  The
>pattern should list r9 and r10 as

It's not "my" pattern, it is taken as an example from the gcc info files, so
the documentation is wrong and should be fixed.

>inputs so that GCC knows not to touch them.  In fact you should leave the
>destinations as open register but make those required inputs so that GCC
>fills them in during register allocation.

The problem is that one cannot on all ports of gcc select
specific registers as input (in that case, r9), but
only register classes.

How am I supposed to tell gcc that (say..) register r13 is NOT to be used as
input in an asm when the target machine has no constraint specificly for
r13? (on the x86 you have almost one class per reg, so that's not a problem,
but this is not true for %ebp... there is NO way to tell gcc NOT to use %ebp
as an input operand, or do I miss sth.?)

      -----==-
      ----==-- _
      ---==---(_)__  __ ____  __       Marc Lehmann
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\
    The choice of a GNU generation

----- End of forwarded message from Marc Lehmann -----

Re: question regarding asm()

[dtm]

I do believe that you really can't do what you desire.  You can 
kinda fake it though, by saying what registers you want particular
variables to be in beforehand:

	register int myvar asm("10");	// r10 on gcc for linux-ppc

-David

On Wed, 8 Oct 1997, Marc Lehmann wrote:

> Sorry to post this question again, but my last e-mail was definitely ignored,
> and the documentation still is wrong.... (And I still have no idea
> how, for example, kernel people are supposed to tell gcc NOT to
> use some registers in an asm that are used in an asm...)
> 
> ----- Forwarded message from Marc Lehmann -----
> 
> David Edelsohn wrote:
> >	Clobber just means that GCC cannot make assumptions about the
> >register after the call, not before.
> 
> That's what I expected, but the docs seems to sugest otherwise..
> 
> >You explicitly use r9 and r10 in your pattern but never tell GCC.  The
> >pattern should list r9 and r10 as
> 
> It's not "my" pattern, it is taken as an example from the gcc info files, so
> the documentation is wrong and should be fixed.
> 
> >inputs so that GCC knows not to touch them.  In fact you should leave the
> >destinations as open register but make those required inputs so that GCC
> >fills them in during register allocation.
> 
> The problem is that one cannot on all ports of gcc select
> specific registers as input (in that case, r9), but
> only register classes.
> 
> How am I supposed to tell gcc that (say..) register r13 is NOT to be used as
> input in an asm when the target machine has no constraint specificly for
> r13? (on the x86 you have almost one class per reg, so that's not a problem,
> but this is not true for %ebp... there is NO way to tell gcc NOT to use %ebp
> as an input operand, or do I miss sth.?)
> 
>       -----==-
>       ----==-- _
>       ---==---(_)__  __ ____  __       Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /       pcg@goof.com
>       -=====/_/_//_/\_,_/ /_/\_\
>     The choice of a GNU generation
> 
> ----- End of forwarded message from Marc Lehmann -----
> 

Re: question regarding asm()

[Jeffrey A Law]

  In message < E0xIhvT-00067k-00.1997-10-08-00-16-23_pgcc_forever@cerebro >you write:
  > David Edelsohn wrote:
  > >	Clobber just means that GCC cannot make assumptions about the
  > >register after the call, not before.
  > 
  > That's what I expected, but the docs seems to sugest otherwise..
Why do you think that?  I've always thought the same as David Edelsohn
about clobbers.

Given this asm:

     asm ("movl %0,r9;movl %1,r10;call _foo"
          : /* no outputs */
          : "g" (from), "g" (to)
          : "r9", "r10");

GCC should avoid allocating any of the inputs to the clobbered registers.

However, on some ports, when there aren't enough registers, GCC can't do
this, and in some cases it can't even tell you that it did something
wrong.  This is especially important on machines with weird register
sets like the x86.

This is _precisely_ why I've told folks in the past to avoid sucking
up all the registers for asms -- particularly Linux folk who seem to
write bigger asms than anyone.


jeff

Re: question regarding asm()

[Richard Henderson]

On Wed, Oct 15, 1997 at 10:05:34PM -0600, Jeffrey A Law wrote:
>   > >	Clobber just means that GCC cannot make assumptions about the
>   > >register after the call, not before.
>   > 
>   > That's what I expected, but the docs seems to sugest otherwise..
> Why do you think that?

  "The input operands are guaranteed not to use any of the clobbered
   registers, and neither will the output operands' addresses, so you
   can read and write the clobbered registers as many times as you like."

That from 'info gcc "c ext" "extended asm"'.

> However, on some ports, when there aren't enough registers, GCC can't do
> this,

Yeah, well, that's the breaks.

> and in some cases it can't even tell you that it did something
> wrong. This is especially important on machines with weird register
> sets like the x86.

Ouch.

> This is _precisely_ why I've told folks in the past to avoid sucking
> up all the registers for asms -- particularly Linux folk who seem to
> write bigger asms than anyone.

It would be nice, and probably solve some of these problems with the
strange and wonderous asm blocks we write, if you could separately
list regs clobbered at input/output/both.

And while I'm wishing, more than 10 arguments, which is feasable
when all that's needed are memory and immediate constraints. 

And being able to specify immediate inputs to file scope asm blocks
so I can easily write assembly thunks that use offsetof to communicate
with C structs.


r~

Re: question regarding asm()

[Jeffrey A Law]

  In message < 19971016013930.22185@dot.cygnus.com >you write:
  > On Wed, Oct 15, 1997 at 10:05:34PM -0600, Jeffrey A Law wrote:
  >   "The input operands are guaranteed not to use any of the clobbered
  >    registers, and neither will the output operands' addresses, so you
  >    can read and write the clobbered registers as many times as you like."
  > 
  > That from 'info gcc "c ext" "extended asm"'.
Right.  That seems pretty unambigious to me.

  > > and in some cases it can't even tell you that it did something
  > > wrong. This is especially important on machines with weird register
  > > sets like the x86.
  > 
  > Ouch.
Yup.  I wouldn't be suprised if this ends up being similar to the problems
with passing args in registers for SMALL_REGISTER_CLASS machines.


jeff

Re: question regarding asm()

[Bernd Schmidt]

> Yup.  I wouldn't be suprised if this ends up being similar to the problems
> with passing args in registers for SMALL_REGISTER_CLASS machines.

I'd like to mention here that the reload patch I posted here a few months ago
does not only cause better code to be generated on the x86, it should also
solve these problems by taking hard register lifetimes into account and only
using free hard regs for reloads.

Bernd

Re: question regarding asm()

[Jeffrey A Law]

  In message < Pine.SOL.3.90.971017101906.7483B-100000@hutch.informatik.rwth-aachen.de >you write:
  > I'd like to mention here that the reload patch I posted here a few months
  > ago does not only cause better code to be generated on the x86, it should also
  > solve these problems by taking hard register lifetimes into account and only
  > using free hard regs for reloads.
I think that patch is worth looking at, but right now the priority is issues
for the release.  Your improvement to reload_cse is also near the top of my
list once we get the release out.

jeff

Re: question regarding asm()

[Michael Meissner]

Bernd Schmidt writes:
| > Yup.  I wouldn't be suprised if this ends up being similar to the problems
| > with passing args in registers for SMALL_REGISTER_CLASS machines.
| 
| I'd like to mention here that the reload patch I posted here a few months ago
| does not only cause better code to be generated on the x86, it should also
| solve these problems by taking hard register lifetimes into account and only
| using free hard regs for reloads.

I hoped to start looking at this.  I am concerned about breaking the
Linux kernel due to changing semantics.  Have you considered changing
it so it still has the same semantics regarding input/output reloads?

-- 
Michael Meissner, Cygnus Solutions (East Coast)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

Re: question regarding asm()

[Bernd Schmidt]

> I hoped to start looking at this.  I am concerned about breaking the
> Linux kernel due to changing semantics.  Have you considered changing
> it so it still has the same semantics regarding input/output reloads?

The kernel has been broken before by GCC changes. You can't compile Linux 1.2
with GCC 2.7.2.
The problem is, what exactly _are_ the current semantics for asm statements
on the x86? As far as I can tell, the clobbers are more or less ignored,
which is clearly wrong. I think it would be best to make the constraint
checking for asm statements more strict, even if that means that kernel
patches will become necessary.
BTW, could we increase MAX_RECOG_OPERANDS right now? This would make writing
correct asm statements a lot easier. I'll provide a patch if necessary.

Bernd

Re: question regarding asm()

[Christian Iseli]

Hello again...

I see one of your reload patches got into the latest snapshot... great!

I twiddled a little bit the other one (dated August 21...) and applied
it as well.  I still had some cases where the compiler stopped saying
"fixed or forbidden register was spilled...".  So I whipped up the
following kludge and now my test cases seem to compile fine (and run
fine too... :-)

Do you see anything blatantly wrong with this fix to your patch?

Thanks for your feedback,
					Christian

*** reload1.c.orig	Tue Dec  9 14:27:30 1997
--- reload1.c	Tue Dec  9 15:47:06 1997
*************** order_regs_for_reload (chain, global)
*** 1550,1563 ****
        hard_reg_n_uses[i].regno = i;
        hard_reg_n_uses[i].uses = 0;
  
!       if (fixed_regs[i] || i == HARD_FRAME_POINTER_REGNUM)
  	{
  	  SET_HARD_REG_BIT (bad_spill_regs, i);
  	  continue;
  	}
  
        regno = chain->inverse_renum_before[i];
!       if (regno < 0)
  	SET_HARD_REG_BIT (bad_spill_regs, i);
        else if (regno > 0 && ! REGNO_REG_SET_P (spilled_pseudos, regno))
  	{
--- 1550,1566 ----
        hard_reg_n_uses[i].regno = i;
        hard_reg_n_uses[i].uses = 0;
  
!       if (fixed_regs[i]
! 	  || (i == HARD_FRAME_POINTER_REGNUM
! 	      && (!SMALL_REGISTER_CLASSES
! 		  || frame_pointer_needed)))
  	{
  	  SET_HARD_REG_BIT (bad_spill_regs, i);
  	  continue;
  	}
  
        regno = chain->inverse_renum_before[i];
!       if (regno < 0 && !SMALL_REGISTER_CLASSES)
  	SET_HARD_REG_BIT (bad_spill_regs, i);
        else if (regno > 0 && ! REGNO_REG_SET_P (spilled_pseudos, regno))
  	{
*************** order_regs_for_reload (chain, global)
*** 1571,1577 ****
  	}
  
        regno = chain->inverse_renum_after[i];
!       if (regno < 0)
  	SET_HARD_REG_BIT (bad_spill_regs, i);
        else if (regno > 0 && ! REGNO_REG_SET_P (spilled_pseudos, regno)
  	       && regno != chain->inverse_renum_before[i])
--- 1574,1580 ----
  	}
  
        regno = chain->inverse_renum_after[i];
!       if (regno < 0 && !SMALL_REGISTER_CLASSES)
  	SET_HARD_REG_BIT (bad_spill_regs, i);
        else if (regno > 0 && ! REGNO_REG_SET_P (spilled_pseudos, regno)
  	       && regno != chain->inverse_renum_before[i])

Re: question regarding asm()

[Christian Iseli]

Thanks for the feedback.

> (parallel
>  (set (mem:DI (plus:SI (reg:SI r1) (reg:SI r2)))
>       (plus:DI (mem:DI (plus:SI (reg:SI r3) (reg:SI r4)))
>                (mem:DI (plus:SI (reg:SI r5) (reg:SI r6)))))
>  (clobber (reg:SI r7)))

Yup, this looks familiar... :-)  In my case it's SI mode, with
a single register in the address (plus a const), but it's probably
the same problem.

Any idea how to "improve" find_reloads anyone? :-) :-)

					Christian

Re: question regarding asm()

[Bernd Schmidt]

> 
> I'm configuring GCC on a small embedded 8-bit microprocessor named CoolRISC
[snip - problem description deleted]

> I'm not yet sure how to teach reload to solve this problem.  In the meantime, I
> tried Bernd's patch and it seems to solve (or avoid) partly the problem.  The
> resulting compiler produced slightly better code, but died a few times with the
> "forbidden register was spilled" message.  Most of the time, GCC was trying to
> spill the (unneeded) frame pointer.  I applied a small patch to tell reload that
> it's OK to spill the FP when it is not needed and now I'm left with only a few
> cases where reload dies while trying to spill a forbidden (pseudo) register.

> *RAMBLING MODE OFF*
> 
> Bernd, does your patch try to address my reload problem, or is it merely a
> side effect?

I think my patch does not try to solve your problem, but since it reduces
the number of spilled registers, it's quite possible that it can avoid the
problems in some cases. My patch is mainly concerned with the allocation of
reload registers after find_reloads has done the work. There's another area
in reload that may result in suboptimal code, and which may cause your
problems: find_reloads does not try to minimize the number of registers
needed, it tries to minimize the number of instructions that need to be
generated by reload. That makes sense on machines with many registers,
but it hurts on others (like the x86). In fact, there have been cases where
there were spill failures like the one you described on the x86. I don't
recall the problem exactly, but I _think_ the instruction that triggered it
looked like this (adddi3 pattern):

(parallel
 (set (mem:DI (plus:SI (reg:SI r1) (reg:SI r2)))
      (plus:DI (mem:DI (plus:SI (reg:SI r3) (reg:SI r4)))
               (mem:DI (plus:SI (reg:SI r5) (reg:SI r6)))))
 (clobber (reg:SI r7)))

where reload decided it needed 7 registers, and the CPU unfortunately only
had 6 available. Of course it would be possible to simply reload all of the
addresses into one register each, so it would have been perfectly possible
to reload this instruction using only four registers (but more reload
instructions) without a compiler abort.
(yes, it's not exactly the same problem, but a closely related one)

Bernd

Re: question regarding asm()

[Christian Iseli]

> You should rather use an extra hard register number for the frame pointer,
> and then eliminate this frame pointer either to the hard frame pointer or
> to the stack.
         ^^^^^
(I guess you mean the stack pointer...)

Hmm...  That's what I'm doing already.  reload, at least with Bernd's
patch applied, puts the HARD_FRAME_POINTER_REGNO in the bad_spill_regs,
even when frame_pointer_needed is 0.  That's what I patched...

					Christian

Re: question regarding asm()

[Joern Rennecke]

> resulting compiler produced slightly better code, but died a few times with the
> "forbidden register was spilled" message.  Most of the time, GCC was trying to
> spill the (unneeded) frame pointer.  I applied a small patch to tell reload that
> it's OK to spill the FP when it is not needed and now I'm left with only a few

You should rather use an extra hard register number for the frame pointer,
and then eliminate this frame pointer either to the hard frame pointer or
to the stack.

Re: question regarding asm()

[Christian Iseli]

> Bernd Schmidt writes:
> | > Yup.  I wouldn't be suprised if this ends up being similar to the problems
> | > with passing args in registers for SMALL_REGISTER_CLASS machines.
> | 
> | I'd like to mention here that the reload patch I posted here a few months ago
> | does not only cause better code to be generated on the x86, it should also
> | solve these problems by taking hard register lifetimes into account and only
> | using free hard regs for reloads.
> 
> I hoped to start looking at this.  I am concerned about breaking the
> Linux kernel due to changing semantics.  Have you considered changing
> it so it still has the same semantics regarding input/output reloads?

*RAMBLING MODE ON*

I tried the patch and it seems to solve many problems for me.

I'm configuring GCC on a small embedded 8-bit microprocessor named CoolRISC
(< http://www.coolrisc.com/ > in case you want more info... :-)

We will be transfering the copyright of the whole thing to the FSF shortly, and send
the source for inclusion in the GCC and/or EGCS distributions, but
in case anybody wants a sneak preview, I can probably arrange that...

Anyway, I've come across quite a few stumbling blocks while developing this
back-end, and one of the major pain I have is with reload...

The first thing to say is that registers are scarce.  16 8-bit registers, of which
1 is unusable (status register) and 1 is an accumulator which gets clobbered by most
operations.  Adresses use 16 bits, and thus 2 registers are needed to hold one address.
4 groups of 2 registers can be used to reference memory.  One of those group is used
as the stack pointer, leaving 3 free groups, except when a frame pointer is needed...
Needless to say, a program compiled without -O (and thus needing a frame pointer) has
little chance of success.

So I have seen a lot of messages "Cannot find a register to spill"...

The usuall scenario goes thusly; we have a bunch of insns looking like so:
 1 (set (reg A) something)
 2 (set (reg B) (mem (plus (reg A) const)))
 3 (set (reg C) something)
 4 (set (reg D) (mem (plus (reg C) const)))
 5 (set (mem (plus (reg B) const))
        (some_op (mem (plus (reg B) const)) (mem (plus (reg D) const)))

Local-alloc does its thing and is able to allocate A and B to hard register P1
and C and D to hard register P2.

Now reload starts and pretty soon discovers that it has to spill hard register P1
to use it as a reload reg.  Things now look like this:
 1 (set (reg A) something)
 2 (set (reg B) (mem (plus (reg A) const)))
 3 (set (reg P2) something)
 4 (set (reg P2) (mem (plus (reg P2) const)))
 5 (set (mem (plus (reg B) const))
        (some_op (mem (plus (reg B) const)) (mem (plus (reg P2) const)))

Then, it comes back to insn 5 and calls
find_reloads.  The conclusion of find_reloads is that it will need four
address registers (of class ADDR_REGS), plus 2 optional reloads of the mem
parameters.  Strangely enough, all reloads end up being some form of input* reloads.
Since at most 3 address registers can be found, reload dies miserably.
Of course, by carefully looking at the RTL, it is clear that (in this example) 1
address registers would be enough.

I'm not yet sure how to teach reload to solve this problem.  In the meantime, I
tried Bernd's patch and it seems to solve (or avoid) partly the problem.  The
resulting compiler produced slightly better code, but died a few times with the
"forbidden register was spilled" message.  Most of the time, GCC was trying to
spill the (unneeded) frame pointer.  I applied a small patch to tell reload that
it's OK to spill the FP when it is not needed and now I'm left with only a few
cases where reload dies while trying to spill a forbidden (pseudo) register.

BTW, I use the PlumHall validation suite to test the compiler...  When I have a
little time, I'll try to use the GCC test suite.

*RAMBLING MODE OFF*

Bernd, does your patch try to address my reload problem, or is it merely a
side effect?  BTW, your patch does not apply cleanly on egcs-971023, the last
hunk of local-alloc.c fails.  I think the hunk below is correct though...

Seems I used enough bandwisth already...  Anybody care to comment on this?

Cheers,
					Christian


*************** block_alloc (b)
*** 1710,1726 ****
        {
  	for (i = qty_first_reg[q]; i >= 0; i = reg_next_in_qty[i])
  	  reg_renumber[i] = qty_phys_reg[q] + reg_offset[i];
- 	if (qty_scratch_rtx[q])
- 	  {
- 	    if (GET_CODE (qty_scratch_rtx[q]) == REG)
- 	      abort ();
- 
- 	    qty_scratch_rtx[q] = gen_rtx (REG, GET_MODE (qty_scratch_rtx[q]),
- 					  qty_phys_reg[q]);
- 
- 	    scratch_block[scratch_index] = b;
- 	    scratch_list[scratch_index++] = qty_scratch_rtx[q];
- 	  }
        }
  }
  \f
--- 1583,1588 ----

Re: question regarding asm()

[Marc Lehmann]

David Edelsohn wrote:
>	Clobber just means that GCC cannot make assumptions about the
>register after the call, not before.

That's what I expected, but the docs seems to sugest otherwise..

>You explicitly use r9 and r10 in your pattern but never tell GCC.  The
>pattern should list r9 and r10 as

It's not "my" pattern, it is taken as an example from the gcc info files, so
the documentation is wrong and should be fixed.

>inputs so that GCC knows not to touch them.  In fact you should leave the
>destinations as open register but make those required inputs so that GCC
>fills them in during register allocation.

The problem is that one cannot on all ports of gcc select
specific registers as input (in that case, r9), but
only register classes.

How am I supposed to tell gcc that (say..) register r13 is NOT to be used as
input in an asm when the target machine has no constraint specificly for
r13? (on the x86 you have almost one class per reg, so that's not a problem,
but this is not true for %ebp... there is NO way to tell gcc NOT to use %ebp
as an input operand, or do I miss sth.?)

      -----==-
      ----==-- _
      ---==---(_)__  __ ____  __       Marc Lehmann
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\
    The choice of a GNU generation

question regarding asm()

[Marc Lehmann]

in the info file, this asm is given as an example of specifying registers to
be clobbered:

>     asm ("movl %0,r9;movl %1,r10;call _foo"
>          : /* no outputs */
>          : "g" (from), "g" (to)
>          : "r9", "r10");

Now I have a question.. is gcc supposed to avoid allocating r9 to %1 ??

in fact, gcc tries to avoid allocating "clobbered" registers for input operands,
but if there are no registers left gcc will nevertheless use them.

So, under register pressure, gcc might use r9 for input operand %1.

There was a problem in the linux kernel because egcs allocated
a register for an input operand that was also in the clobberlist
(and actually was overwritten before the input operand was used).

so whats wrong?

a) the example in the documentation
b) gcc, because it allocates wrong registers for the input operands
c) me, because I'm totally confused tonight..

;?

      -----==-
      ----==-- _
      ---==---(_)__  __ ____  __       Marc Lehmann
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\
    The choice of a GNU generation