Hi Alan, the problem you point out is really just the tip of the iceberg -- currently reload frequently decides it *will* perform an action in the future, and assumes that other code will anyway behave as if that action had already been completed ...
This is why e.g. the 'm' constraint accepts *any* MEM without checking whether the address is valid. Extra memory constraint checking needs to similarly account for future reload actions currently ... > a) Before matching constraints in find_reloads, substitute dummy regs > for any reloads that have been identified. I'm not sure how much work > is involved in doing this, or whether it is even possible. It sounds > like this would be the best solution technically, as then the output > of LEGITIMIZE_RELOAD_ADDRESS is properly checked. I'd really like to see something like this in the future -- first steps have been done in the reload-branch. This is unlikely to be fixable in the short term, though. > b) Modify LEGITIMIZE_RELOAD_ADDRESS to return a constraint letter that > the address is guaranteed to match after reloading. A bit of mechanical > work changing all targets. This is probably not general enough -- in LEGITIMIZE_RELOAD_ADDRESS you have no idea what the current insn is, or what constrains it can possibly accept -- if the result of LEGITIMIZE_RELOAD_ADDRESS can match multiple extra memory constraints, which one should you select? > c) Modify the ppc 'Z' constraint to match the indexed address reload > generates. This would rely on the pattern we generate in > LEGITIMIZE_RELOAD_ADDRESS never being generated elsewhere. This would fit in the spirit of how reload currently does things. Seeing as the 'temporary' address created by LEGITIMIZE_RELOAD_ADDRESS is non-canonical RTL and thus shouldn't occur elsewhere, such a test should be fine, in particular if done under if (reload_in_progress). > d) Hacks like the patch below, that effectively perform the reload > substitution with a dummy reg. I fear this isn't proper, even though it > seems to work.. I'm not sure this is safe, although I don't see right away why it would break either ... Overall, I'd tend to prefer something along the lines of (c), in particular as it would also catch the cases where LEGITIMIZE_RELOAD_ADDRESS isn't actually involved, as you note: > (*) This is exactly what code in find_reloads_address does on > encoutering invalid indexed address. The trouble is that its > transformation isn't valid until the reloads are done, and we check > constraints before doing the substitutions. :-( Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
