https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 29 Apr 2019, amker at gcc dot gnu.org wrote: > 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. I thought 'symbol' in move_fixed_address_to_symbol was really meant to be a [relocatable] absolute address. A stack var can be still moved to 'base' (and we do not account for the stack offset in IVOs compute - that will either be forwarded to 'offset' during RTL or as you said stay as separate stmt) > > > > 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. I think the only way to avoid propagating into it is to re-materialize the propagated value right before the TARGET_MEM_REF. There's no good way to forbid propagating on the base of destination stmt properties. But I wonder if RTL expansion, based on this, cannot easily undo such propagation?
