Re: About EXTRA_ADDRESS_CONSTRAINT

Re: About EXTRA_ADDRESS_CONSTRAINT

[Ulrich Weigand]

Alexandre Courbot wrote:

>The insn that is generated by the + operator is of the form:
>
>(set (mem (const (plus (symbol_ref "obj") (const_int x))))
>     (plus (mem (symbol_ref "var")) (const_int 2)))
>
>During reloading, I designed my EXTRA_ADDRESS_CONSTRAINT marked constraint to
>detect the destination was a member of a struct, and thus it changed this
>insn into:
>
>(set (reg REG) (plus (mem (symbol_ref "var")) (const_int 2)))
>(set (mem (const (plus (symbol_ref "obj") (const_int x))))
>     (reg REG))

But this is a simple reload of the value into a register; you shouldn't
need any of the 'special stuff' for that.

>Which was fine! But unfortunately it seems to be risky :( Using
>EXTRA_MEMORY_CONSTRAINT doesn't do what I need (it stores the address of the
>location to store the result into into the register and do a mem on it -
>which I can't reflect in the generated code)
>
>The pattern that matches this is:
>(set (match_operand 0 "nonimmediate_operand" "=Q")
>     (plus (match_operand 1 "general_operand" "Q")
>           (match_operand 2 "general_operand" "Q")))
>
>(Q is my "doesn't belong to a structure" constraint)

Simply define 'Q' as a normal EXTRA_CONSTRAINT, and rewrite the pattern as

(set (match_operand 0 "nonimmediate_operand" "=Qr")
     (plus (match_operand 1 "general_operand" "Qr")
           (match_operand 2 "general_operand" "Qr")))

so that reload will know it can reload into a register in case the 'Q'
doesn't match exactly.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: About EXTRA_ADDRESS_CONSTRAINT

[Alexandre Courbot]

> >(set (reg REG) (plus (mem (symbol_ref "var")) (const_int 2)))
> >(set (mem (const (plus (symbol_ref "obj") (const_int x))))
> >     (reg REG))
>
> But this is a simple reload of the value into a register; you shouldn't
> need any of the 'special stuff' for that.

Mmm. I guess I have difficulties clearly understanding the reload mechanism. I 
haven't found a part in the manual that formally explains what happens there 
- from what I understand, values which constraints doesn't match are just 
reloaded into registers - but it look like it does a bit more actually.

> Simply define 'Q' as a normal EXTRA_CONSTRAINT, and rewrite the pattern as
>
> (set (match_operand 0 "nonimmediate_operand" "=Qr")
>      (plus (match_operand 1 "general_operand" "Qr")
>            (match_operand 2 "general_operand" "Qr")))
>
> so that reload will know it can reload into a register in case the 'Q'
> doesn't match exactly.

It works flawlessly. I thought it wasn't necessary to put the 'r' as my 'Q' 
constraint obviously includes registers. I'm a bit confused by this. Reading 
the Machine Descriptions chapter again didn't help understanding why 'r' is 
needed here. Maybe it is marked in some way so the compiler knows how to 
reload to it, while my Q constraint obviously isn't marked?

Anyway, thanks a lot for your help - you have been extremly helpful and I hope 
to understand clearly what happens during reloading thanks to this! ;)
Alex.

Re: About EXTRA_ADDRESS_CONSTRAINT

[Ulrich Weigand]

Alexandre Courbot wrote:

>It works flawlessly. I thought it wasn't necessary to put the 'r' as my 'Q'
>constraint obviously includes registers. I'm a bit confused by this. Reading
>the Machine Descriptions chapter again didn't help understanding why 'r' is
>needed here. Maybe it is marked in some way so the compiler knows how to
>reload to it, while my Q constraint obviously isn't marked?

Yes.  The point of reload is not *only* to make sure the operands match
the constraints as-is (maybe selecting an alternative), but also to make
changes to the operands to *make* them match the constraints if necessary.

For the second part, reload needs to understand exactly what the constraint
letter means; this understanding is hard-coded into reload.  Thus, for
example, it knows that if an operand does not fit the 'r' constraint, it
can be made fit by choosing a register from class GENERAL_REGS and reloading
the operand into that register.  Similar for the other standard constraint
letters.

However, for platform-specific EXTRA_CONSTRAINTs, reload does not know
how to make them fit if they don't match right away.   Thus is can make
sense to offer a standard constraint in addition to the extra one, so that
reload can use the standard constraint to make the operand fit if it
matches neither the standard nor the extra one.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: About EXTRA_ADDRESS_CONSTRAINT

[Alexandre Courbot]

> >I've defined a special constraint for my port describing members of
> > structures because I need to access structure members via a special
> > method of the target language (i.e. there are get/set instructions to
> > access members). Therefore I needed such access to structure members to
> > be reloaded when needed. As I can't work with addresses on my target, I
> > wanted the *content* of the member to be reloaded, not the address
> > (otherwise it would place the address into a register and generate a set
> > to the address contained in that register, which I can't handle). So
> > everything suggests me to mark my constraint with
> > EXTRA_ADDRESS_CONSTRAINT.
>
> I'm not sure I understand the specific requirements your port has, could
> you elaborate a bit?  In particular, I don't understand the bit about
> 'can't work with addresses' -- how can you implement pointers then?

You're right, I've not been clear enough. Let me explain with an example then. 
I'm porting GCC to generate code for an abstract language. That's why there 
are no explicit pointers. I don't intend to get all GCC to work in these 
conditions - I just need support for some things.

In my port, the C structures are changed into "objects" that have the same 
members. Thus you can request a member with the "get" and "set" methods. For 
instance:
obj.member = 2;

Will be compiled to (simplified version, normally indexes are used, not 
strings):
obj set "member" 2

and 
var = obj.member;

to
var <- obj get "member"

This means that if I do an addition for which the result should be placed in 
the member of a structure, I'll need an extra placeholder (what we call a 
"temporary", and is mapped to registers in my port):
obj.member = var + 2;

will be turned into:
.temp t0
t0 <- var + 2
obj set "member" t0

The insn that is generated by the + operator is of the form:

(set (mem (const (plus (symbol_ref "obj") (const_int x))))
       (plus (mem (symbol_ref "var")) (const_int 2)))

During reloading, I designed my EXTRA_ADDRESS_CONSTRAINT marked constraint to 
detect the destination was a member of a struct, and thus it changed this 
insn into:

(set (reg REG) (plus (mem (symbol_ref "var")) (const_int 2)))
(set (mem (const (plus (symbol_ref "obj") (const_int x))))
       (reg REG))

Which was fine! But unfortunately it seems to be risky :( Using 
EXTRA_MEMORY_CONSTRAINT doesn't do what I need (it stores the address of the 
location to store the result into into the register and do a mem on it - 
which I can't reflect in the generated code)

The pattern that matches this is:
(set (match_operand 0 "nonimmediate_operand" "=Q")
              (plus (match_operand 1 "general_operand" "Q")
                    (match_operand 2 "general_operand" "Q")))

(Q is my "doesn't belong to a structure" constraint)

> In any case, it doesn't appear to be what EXTRA_ADDRESS_CONSTRAINT
> was intended for. Maybe you need to consider SECONDARY_RELOAD_CLASS
> and/or SECONDARY_MEMORY_NEEDED?

AFAIK these macros are only useful to control the reloading of registers. 
Therefore I don't think they are useful in cases like mine (mem to mem 
moves).

> >I'd like to know: is it safe to use a constraint marked with
> >EXTRA_ADDRESS_CONSTRAINT with another predicate than address_operand?
>
> No.

I'm really open to any suggestion that would allow me to do it a safe way 
then! :)

Thanks for the reply,
Alex.

Re: About EXTRA_ADDRESS_CONSTRAINT

[Ulrich Weigand]

Alexandre Courbot wrote:

>I've defined a special constraint for my port describing members of structures
>because I need to access structure members via a special method of the target
>language (i.e. there are get/set instructions to access members). Therefore I
>needed such access to structure members to be reloaded when needed. As I
>can't work with addresses on my target, I wanted the *content* of the member
>to be reloaded, not the address (otherwise it would place the address into a
>register and generate a set to the address contained in that register, which
>I can't handle). So everything suggests me to mark my constraint with
>EXTRA_ADDRESS_CONSTRAINT.

I'm not sure I understand the specific requirements your port has, could
you elaborate a bit?  In particular, I don't understand the bit about
'can't work with addresses' -- how can you implement pointers then?

In any case, it doesn't appear to be what EXTRA_ADDRESS_CONSTRAINT
was intended for. Maybe you need to consider SECONDARY_RELOAD_CLASS
and/or SECONDARY_MEMORY_NEEDED?

>However, the manual says "Any constraint marked as EXTRA_ADDRESS_CONSTRAINT
>can only be used with the address_operand predicate." I don't really
>understand why because (1) I use my constraint with plenty of predicates, and
>no address_operand and it does the job well, and (2) as constraints marked
>with it indicates that a reload should be done on what's pointed by the
>address, I can't think of a suitable usage with address_operand.

No, that's not true: a constraint marked with EXTRA_ADDRESS_CONSTRAINT
means the *address* should be reloaded, not what it points to.  It can
only be used with instructions like 'load address'.

In short, a constraint marked with EXTRA_ADDRESS_CONSTRAINT is a
platform-specific restricted variant of the 'p' constraint, in the
same sense as a constraint marked with EXTRA_MEMORY_CONSTRAINT is
a platform-specific restricted variant of the 'm' constraint.

>I'd like to know: is it safe to use a constraint marked with
>EXTRA_ADDRESS_CONSTRAINT with another predicate than address_operand?

No.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

About EXTRA_ADDRESS_CONSTRAINT

[Alexandre Courbot]

Hello everybody,

I've defined a special constraint for my port describing members of structures 
because I need to access structure members via a special method of the target 
language (i.e. there are get/set instructions to access members). Therefore I 
needed such access to structure members to be reloaded when needed. As I 
can't work with addresses on my target, I wanted the *content* of the member 
to be reloaded, not the address (otherwise it would place the address into a 
register and generate a set to the address contained in that register, which 
I can't handle). So everything suggests me to mark my constraint with 
EXTRA_ADDRESS_CONSTRAINT.

However, the manual says "Any constraint marked as EXTRA_ADDRESS_CONSTRAINT 
can only be used with the address_operand predicate." I don't really 
understand why because (1) I use my constraint with plenty of predicates, and 
no address_operand and it does the job well, and (2) as constraints marked 
with it indicates that a reload should be done on what's pointed by the 
address, I can't think of a suitable usage with address_operand.

I'd like to know: is it safe to use a constraint marked with 
EXTRA_ADDRESS_CONSTRAINT with another predicate than address_operand? If not, 
is there another, safe way to do what I want? I've tried plenty of things 
with EXTRA_MEMORY_CONSTRAINT, but as it reloads addresses it doesn't seem to 
be for me.

Any comment or advice welcome,
Thanks,
Alex.