Re: decl_conflicts_with_clobbers_p problem

[Gunther Nikl <gni at gecko dot de>]

On Fri, Mar 14, 2003 at 01:14:52PM +0100, Hans-Peter Nilsson wrote:
> > Date: Fri, 14 Mar 2003 12:21:18 +0100
> > From: Gunther Nikl <gni at gecko dot de>
> 
> > > Or without code changes elsewhere than
> > > the macro definition, use a trick like
> > >  #define LP1NR(offs, name, t1, v1, r1, bt, bn) LP1NR_##r1 (offs, name, t1, v1, bt, bn)
> > > and define different
> > >  #define LP1NR_a1(offs, name, t1, v1, r1, bt, bn) ...
> > >  #define LP1NR_d0(offs, name, t1, v1, r1, bt, bn) ...
> > > with contents where each different "r1" is listed as output and
> > > not in the clobber list?  Or just parametrize the clobber list?
> > 
> >   This would result in a lot of macros because the arguments are in a
> >   "random" order and unpredictable.
> 
> So there's not just *one* register, as was in your example?

  That was only an example. I thought I made that clear. Sorry, that I
  wasn't.

> >   Yes, according the (3.x?) documentation the asm is wrong.
> 
> As I said, the documentation also said that before the error
> message was implemented.

  I didn't question that.

> > However, I have
> >   never seen incorrect code beeing generated (which doesn't prove anything,
> >   granted) and I have used GCC alot on the system in question where these
> >   asm statements are required.
> 
> Well, a programmer here saw it happen.  See the URL I quoted.

  I have. Its slightly different to my asm statement(s). My asm constructs
  place its arguments in the destination registers before the asm using
  local register variables. The asm (which is a function call only)
  invalidates some input registers (the scratch ones if there are any).
  Note: thats what the asm was _supposed_ to do. I understand that the
  asm statement is invalid according to the documentation.

> That's really enough, isn't it?  Having GCC corrected to work
> according to the documentation saves *you* the trouble to trip
> over a code-generation compiler bug.

  I don't question that either.

> I can't really understand your argument.

  It wasn't meant as an argument. I did only state _my_ experience with
  extended asm statements with overlaps (of clobbers and inputs). Inputs
  for an asm placed in local register variables aren't mentioned in the
  GCC documentation prior to 3.0. GCC catching errors at compile time is
  appreciated.

> >   I guess creating an appropriate macro for every function is the only
> >   viable solution.
> 
> Well, good, you found a solution.

  I am not sure anymore that I have a solution. :-(

  Lets look at you proposed macros again first:

      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : "=r" (_n1)						\
      : "r" (_bn), "0" (_n1)					\
      : "d0", "d1", "a0", "fp0", "fp1", "cc", "memory");	\

  All scratches are marked as clobbered (except the _n1 register). Input
  _n1 has the "0" constraint. Is that necessary (also for other inputs
  if its in an register found in the clobber list) to really invalidate
  the register? What if I have two local register vars assigned to the
  same register with one being (only) input and one being (only) output?

      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : /* no output */						\
      : "r" (_##name##_bn), "rf"(_n1)				\
      : CLOBBER_LIST_EXCLUDING_##r1;				\

  I think the contents of "r1" which is bound to _n1 isn't invalidated
  here but thats what I need or the compiler might use the value in r1
  after the asm which would be wrong.

  You didn't answer my question why having outputs which are not used as
  inputs is wrong. Could you please explain that? I have read the paragraph
  about extended asm multiple times now and I can't find a passage that
  forbids this. I do understand extended asm better than before but I still
  have problems (maybe because english isn't my native tongue). Extended
  asm is a really complicate issue. I wish I could do without.

  Nethertheless, I would really really like to know, why overlaps of
  clobbers with inputs isn't allowed. Yes, its documented but without
  any explanation. It only says:

   "You may not write a clobber description in a way that overlaps with
    an input or output operand. [...] Variables declared to live in specific
    registers (*note Explicit Reg Vars::), and used as asm input or output
    operands must have no part mentioned in the clobber description. There
    is no way for you to specify that an input operand is modified without
    also specifying it as an output operand."

  Overlaps might cause incorrect code to be generated as your example shows.
  Ok, for outputs wich are marked as clobbered. Why do inputs marked as
  clobbered pose problems? All I want to know is why GCC imposes this
  restriction. And ofcourse I am search for a solution for my problem.

  Thank you,
  Gunther Nikl