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.
