RFD: More flexibility in defining addressing modes

[Ian Lance Taylor]

Bernd Schmidt <bernds_cb1@t-online.de> writes:

> > At this point, would it be easier to understand if we instead passed
> > the complete address to the target in RTL, and the target in the one
> > case returned the register class, and in the other checked the regno?
> 
> Well, you can have several registers in one address, and if you pass
> the whole thing to the backend it won't know which part to look at.

I was imagining that one would pass in the address of the REG in
question.  I don't have any particularly strong objection to your
patch, it just seems to make an already confusing situation somewhat
more confusing.  Adding the RTX code solves the nonorthoganality on
the Blackfin, but there are other types of nonorthogonality in
existing processors, like the MIPS16 in which different registers
support different maximum offsets in unextended instructions.

> > It might even make sense to do something like
> >     (define_address
> >      (plus (match_operand:Pmode 0 "predicate" "constraints")
> >            (match_operand:Pmode 1 "predicate" "constraints")))
> 
> I know.  I got as far as parsing define_address in a few generator programs.
> 
> > Then we can use that instead of GO_IF_LEGITIMATE_ADDRESS,
> > MODE_BASE_REG_REG_CLASS, etc., etc.
> 
> What would we generate from that?  To be worthwhile, it would have to
> be more descriptive than what we have now.  Do we want to generate
> versions of find_reloads or record_address_regs automatically?

I think it's more descriptive than what we have now because it permits
looking at the address as a whole.  I think it might also give us the
opportunity to simplify some parts of reload.  Instead of having a set
of heuristics to generate reload addresses, we could perhaps have a
more coherent scheme, ideally replacing very delicate code like
LEGITIMIZE_RELOAD_ADDRESS.

That is, what we would generate would be be a set of tables and
recognition functions.  These would be used by find_reloads_address,
instead of the current set of heuristics.  They would also be used by
memory_address, instead of LEGITIMIZE_ADDRESS, and by
memory_address_p, instead of GO_IF_LEGITIMATE_ADDRESS.

Ian