On Wed, 18 Jun 2014, Jakub Jelinek wrote: > On Wed, Jun 18, 2014 at 11:56:01AM +0200, Richard Biener wrote: > > > > I just figured that we create &TARGET_MEM_REF [base: a_4, offset: 0] > > from within IVOPTs. That pessimizes further passes unnecessarily. > > > > Bootstrap and regtest running on x86_64-unknown-linux-gnu. > > Isn't that against the comment above it? > ??? As IVOPTs does not follow restrictions to where the base > pointer may point to create a MEM_REF only if we know that > base is valid. > Perhaps it is fine only if addr->offset is integer_zerop?
Oh .... yeah, I guess so. Damn IVOPTs ... (though I wonder what's the difference with MEM[&foo, -4B] then, which we don't catch either). That said, I'm not sure if it really fixes anything not allowing MEM_REFs in all cases. I've found a different workaround for the issue I was facing so I'm dropping this patch instead. Richard. > > 2014-06-18 Richard Biener <rguent...@suse.de> > > > > * tree-ssa-address.c (create_mem_ref_raw): Use proper predicate > > to catch all valid MEM_REF pointer operands. > > > > Index: gcc/tree-ssa-address.c > > =================================================================== > > --- gcc/tree-ssa-address.c (revision 211771) > > +++ gcc/tree-ssa-address.c (working copy) > > @@ -393,7 +393,7 @@ create_mem_ref_raw (tree type, tree alia > > ??? As IVOPTs does not follow restrictions to where the base > > pointer may point to create a MEM_REF only if we know that > > base is valid. */ > > - if ((TREE_CODE (base) == ADDR_EXPR || TREE_CODE (base) == INTEGER_CST) > > + if (is_gimple_mem_ref_addr (base) > > && (!index2 || integer_zerop (index2)) > > && (!addr->index || integer_zerop (addr->index))) > > return fold_build2 (MEM_REF, type, base, addr->offset);
