From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: rth@cygnus.com
Cc: amylaar@cygnus.co.uk, michaelh@ongaonga.chch.cri.nz, rth@cygnus.com, egcs@cygnus.com
Subject: Re: Autoincrement addressing modes
Date: Tue, 17 Mar 1998 13:29:00 -0000
Message-id: <199803172006.UAA18776@phal.cygnus.co.uk>
References: <19980317011632.48302@dot.cygnus.com>
X-SW-Source: 1998-03/msg00587.html

> Good point.  Perhaps the thing to do then is to tie addresses
> to instruction types, a-la 
> 
>   (define_attr "type" "ld,st,lea")
> 
>   (define_address "base"
>     (mem (match_operand:PI 0 "register_operand" "r"))
>     (eq_attr "type" "ld,st,lea")
>     "0(%0)")
> 
>   (define_address "auto_inc"
>     (mem (post_inc (match_operand:PI 0 "register_operand" "r")))
>     (eq_attr "type" "ld")
>     "(%0)+")
> 
> This would then let us have arbitrarily complex conditions that
> the insn must satisfy before the address strictly matches. 

We already have this possibility when recognizing an insn - since every
insn can have an arbitrary condition.
Thus, if we actually need to have the exact insn in order to verify it,
we win nothing compared to the current scheme.

One possible improvement could be if we don't need to have the exact insn,
but only one that matches the right pattern, and then be able to
look at the different alternatives 'by hand' .  If we make the "type"
attribute 'magic', we could probably do some tests for possible addressing
modes without actually modifying the insn - provided that the "type"
attribute of the insn only depends on the alternative, and that
the conditions of the addressing modes are NOT arbitrarily complex,
but only list a list of possible insn types.

> Not sure exactly how we'd notice that insn type "ist" is a store,
> for early (pre-reload) optimizations for things like auto_inc.
> Perhaps with magic attributes on the addresses themselves, though
> it would be nicer to discover these kinds of things rather than
> having to be told.

That is not that hard in flow / regmove when we are dealing with
actual insns, but it seems near impossible for pre-rtl-generation tests
like in expr.c:move_by_pieces .

We probably have to use some sort of approximation, i.e. if the
mode & direction is available for any insn & alternative under some
condition, we presume that it is available.

But if using predicates that the gen* files don't understand will lead to
poor code, maybe we should not use a model that encourages to use them.

To pick up the example from above, we could say:

  (define_address "base"
    (mem (match_operand:PI 0 "register_operand" "r"))
    "ld,st,lea"
    "0(%0)")

and it is implied that "ld,st,lea" is a list of values for the attribute
"type" .

If addressing modes of different operands interfere with each other, it
should in general be possible to express this with sufficiently detailed
instruction alternatives.  If you need anything more complicated, it
should propably go into the insn predicate.