RFA: Fix PR53688

[Michael Matz]

Hi,

On Tue, 19 Jun 2012, Richard Guenther wrote:

> > So, we have to build a memref always and rewrite its type to one
> > representing the real size. Â Note that TYPE_MAX_VALUE may be NULL, so we
> > don't need to check for 'len' being null or not.
> >
> > This fixes the C testcase (don't know about fma 3d), and is in
> > regstrapping on x86_64-linux. Â Okay if that passes?
> 
> Ok.

Thanks, but I now know why we built an INDIRECT_REF :)  
build_simple_mem_ref() only handles some very constrained arguments, 
namely pointers and offseted ADDR_EXPRs when the offset is a constant.  
It doesn't for instance handle &bla->a[i] (it asserts).  So the patch 
trips over the assert in build_simple_mem_ref on "__builtin_memset 
(&p->c[i], 0, 42);".

I could build INDIRECT_REFs always instead of MEM_REFs, this fixes the bug 
too, but it wouldn't generate any MEM_EXPRs anymore, and hence the whole 
bruhaha would be dead code (well, except for alignment setting).

Or I could build MEM_REFs directly, not via build_simple_mem_ref, that 
also works, but leaves us with such MEM_EXPRs sometimes:

  (mem/c:BLK (reg:DI 65) [0 MEM[(void *)&p_1(D)->c[i_2(D)]]+0 A8])

Note the complicated and non-canonical expression in the MEM[].  I'm not 
sure if the disambiguators do anything interesting with such expressions.  
If they aren't we'd safe memory by not generating this MEM_EXPR at all.

If the latter is acceptable, then I indeed can as well wrap everything in 
a MEM_REF like you proposed (possibly with a predicate "simple enough" 
that reflects what build_simple_mem_ref is also checking) and be done with 
it.

So, what should it be?


Ciao,
Michael.