Re: decl_conflicts_with_clobbers_p problem

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Fri, 14 Mar 2003 15:53:41 +0100
> From: Gunther Nikl <gni at gecko dot de>

> > >   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. :-(

Why can't you define one different macro for each syscall that
takes a different set of input, output and clobber registers?
What's so hard about that?  For example, that's how the Linux
syscalls are usually implemented (though the parametrization is
expressed as the number of parameters).

>   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).

The _n1 in the example has to be a register not mentioned in the
clobber list.

> Input
>   _n1 has the "0" constraint. Is that necessary (also for other inputs
>   if its in an register found in the clobber list)

You must not specify it in the clobber list too.  In this
example which you cut down, it's "a1".

> to really invalidate
>   the register?

You mark it as set by the output.  Since the macro does not use
_n1 afterwards, you get the effect you want.

> What if I have two local register vars assigned to the
>   same register with one being (only) input and one being (only) output?

What's unclear?  One will get assigned the output, and the other
will be passing the input value.  No ambiguity, no collision.
If there's a bug, please report.

>       __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.

Correct; I forgot to change inputs and outputs in that example.
Sorry about that and good that you found it out by yourself.

>   You didn't answer my question why having outputs which are not used as
>   inputs is wrong. Could you please explain that?

No, that's not wrong.  But IIRC you wanted to specify the inputs
as (only) *outputs* in the code you sent as a follow-up, and
*that* was wrong.

> 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.

Then implement the construct as a function attribute or builtin
in your port ;-) (Which you say is not in CVS; but isn't it
actually m68k?)

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

Isn't it enough that it simplifes the rules?  What if it was
allowed?  That'd introduce ambiguities and inconsistency with
the corresponding single-register-class-constraint construct.  I
wrote about that in enough detail in the URL I sent.

Anyway, I'm satisfied with the current implementation and rules.
I've explained to you in enough detail why the code I wrote to
identify erroneous asm use is correct when it reports that your
code is wrong.  I don't have to solve your coding problem.
Still, I've made suggestions that should help you get on the
track.  I'm done.

If you're not happy with the asm semantics, the burden falls on
you to provide argumentation and documentation for what should
happen instead, together with test-cases and patches to
implement that.

brgds, H-P