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