Kazu Hirata <[EMAIL PROTECTED]> writes: > Hi Zack, > >> So, the plan: Step 1 introduces - one at a time - target hooks >> corresponding to each of the above macros. All callers are changed to >> use the hooks. ... >> Step 2 is to convert each architecture, one at a time, to make >> target-hook definitions. I think it makes most sense to do each >> architecture in one go, because the definitions of these macros tend >> to be intertwined. ... > > I would swap these two steps. > > Last time I looked at this stuff, I was surprised by how many things > depended on REG_OK_STRICT. Even if macro A does not mention > REG_OK_STRICT, macro B used in A might use REG_OK_STRICT, so it's > difficult to tell in advance which macro depends on REG_OK_STRICT > either directly or indirectly. So I would change each macro to an > architecture-specific function in each architecture first.
I think it's going to be hard to get traction if we do stuff in this order. If we do the target-independent change first, then target maintainers have an obvious goal to work toward. I don't think that the target-independent change will be blocked on not being able to figure out which macros depend on REG_OK_STRICT, because the value of REG_OK_STRICT is obvious in all target-independent .c files. Also, I think it may become clear from making the target-independent change that some of these hooks don't need two variants. (For instance, LEGITIMIZE_ADDRESS is never used in reload.c.) Whether to do one hook with a flag, or two hooks, I'm not certain of. I prefer two hooks from the caller's point of view, because that encodes the different semantics in the name rather than in a trailing 0/1 (or false/true - either way you have to look up the meaning of the argument to understand what's going on). If this turns out to produce massive code duplication in the backends we can revisit on a hook-by-hook basis. zw
