On Fri, 27 Jan 2012, Richard Guenther wrote: > On Fri, 27 Jan 2012, Richard Guenther wrote: > > > On Fri, 27 Jan 2012, Eric Botcazou wrote: > > > > > > So I am testing the following - please tell me whether you are working > > > > on a different fix. > > > > > > I was, but I realized that this would somewhat conflict with your latest > > > patch > > > to expand_assignment, where all MEM_REFs will go through > > > get_inner_reference > > > instead of the regular expander. > > > > > > Can't we avoid doing this if they have BLKmode? Because you cannot get a > > > BLKmode RTX out of this if the base hasn't BLKmode. We would need to > > > spill, > > > like in the regular expander, so we might as well use it. > > > > I was simply trying to save some code-duplication here. I will > > re-work the patch to avoid this as you suggest. Btw, the original > > reason why we handle MEM_REF at all via the get_inner_reference > > path is that if we have MEM_REF[&decl, CST] and decl was not > > committed to memory then the MEM_REF really acts like a > > bitfield insert to a non-MEM (similar to the rvalue case we > > handle in expand_expr_real_1). > > > > I suppose I should split out some predicates that can be shared > > amongst the various TARGET_[MEM_REF] handlers during expansion > > and tighten this one up as well. > > > > > Otherwise, you're the resident expert in aliasing so, if you think that > > > your > > > patchlet is sufficient, fine with me. > > > > Yes, I think it is sufficient for this case. > > > > Now, let me rework that expand_assignment patch a bit. > > Like the following, bootstrapped and tested on x86_64-unknown-linux-gnu. > I'll apply it later unless I hear some objections.
I have applied this now and the SRA side of the fix for PR50444. As far as I know x86 should be ok with alignment-related issues and SRA now - is there still a bug on strict-alignment platforms we know of (thus, with a testcase)? Otherwise I'd rather delay trying to properly expand misaligned MEM_REFs on non-movmisalign STRICT_ALIGNMENT targets to 4.8. I still want to deal with 51528 though. Thanks, Richard.
