https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270

--- Comment #10 from bin cheng <amker at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> (In reply to bin cheng from comment #7)
> > Also, when calling move_fixed_address_to_symbol, fixed_address_object_p
> > looks too restricted, it only considers link time constant address.  In this
> > case, it's an array object in stack.
> 
> But this is because a stack access isn't $reloc but $sp + offset and thus
> _not_ a symbol.
>From ivopts/loop's point of view, the address ($sp + offset) is loaded into
register, then the register is used to address elements in array.  In other
words, it doesn't really matter if the address is global and determined by
linker or local and determined by stack frame.

> 
> But as you noticed IVOPTs computing TARGET_MEM_REF so "early" is a bit
> brittle due to later eventual forwardings.  And those forwardings are
> hard to avoid because they affect fundamental predicates like
> may_propagate_copy where we decide early whether we can propagte into
> all uses before actually visiting them.
Can we avoid propagating into TARGET_MEM_REF if it creates invalid addressing
mode?  IIUC, passes (like ivopts, slsr) creating TARGET_MEM_REF do generate
"correct" addressing mode, it doesn't make much sense to create invalid ones
afterwards.

Reply via email to