RE: Plan for cleaning up the "Addressing Modes" macros

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>From: gcc-owner On Behalf Of Zack Weinberg 
>Sent: 28 February 2005 02:57

> 1) These are the macros subject to REG_OK_STRICT.  
              [ ... snip! ... ]
>    Also, any macro which uses any of the above macros is perforce
>    affected.
> 
> 2) Several of these macros are specified to alter control flow.  They
>    take a label as an argument, and should "goto" it under specified
>    conditions.  
              [ ... snip! ... ]
>    Because of this, they are used in an
>    obscure fashion (especially the latter two) and are difficult to
>    define as function calls.  Which brings us to ...
> 
> 3) The definitions of these macros are necessarily complicated on a
>    lot of architectures, so that it is desirable to take them
>    out-of-line into the CPU.c file, but this is difficult because of
>    points 1 and 2.

  Hmmm, actually, I would say that moving these macro definitions into the
cpu.c files is a fairly mechanical and trivial transformation.  Given:

${CPU}.h:
#define GO_IF_LEGITIMATE_ADDRESS(MODE,X,ADDR) \
  if ( .... some very hairy conditional depending on REG_OK_STRICT ) \
    goto ADDR;

you just redefine it as

${CPU}.h
#define GO_IF_LEGITIMATE_ADDRESS(MODE,X,ADDR) \
  if (${CPU}_go_if_legitimate_address ((MODE), (X), (REG_OK_STRICT)) \
    goto ADDR;

${CPU}.c
int ${CPU}_go_if_legitimate_address (enum machine_mode mode, rtx x, int
reg_ok_strict)
{
  return ( ... same conditional s/REG_OK_STRICT/reg_ok_strict/g );
}


> In order to do this in a sensible manner, we need to decouple problems
> 1 and 2 above, and we need to deal with problem 1 from the caller's
> side, by making it explicit which behavior is expected at which call
> sites.  Conveniently, the introduction of a target hook in DJ's style
> (that is, with a default that invokes the old macro) does exactly
> this.  For macros that are expected to vary with REG_OK_STRICT, we
> replace with two hooks; for macros that should not vary, we replace
> with one.  (Even if a macro has been defined to vary, we don't need
> two hooks unless it is used both inside and outside reload.c.)

  I think parameterizing the hooks by explicitly passing REG_OK_STRICT
rather than splitting them in two might be a bit less messy?  Bearing in
mind that all the existing macros expect to deal with both STRICT and
non-STRICT, it seems to me it would be a smaller stepwise change: you'd not
have to worry about going through unfamiliar backends separating out two
sets of behaviours/semantics from one macro into two separate code blocks
and worrying about preserving the exact old behaviour.

  Of course, the two hooks could always just be wrappers that call a unified
function underneath, one passing false and one passing true to the strict
parameter.  <shrug>  Guess there's not much in it after all.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....