On Tue, Jun 19, 2012 at 12:13 PM, Michael Matz <m...@suse.de> wrote: > 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?
The MEM_REF is acceptable to the tree oracle and it can extract points-to information from it. Thus for simplicity unconditionally building the above is the best. We can always massage both fold to handle more complex cases (like the POINTER_PLUS_EXPR case) and set_mem_attributes to canonicalize / strip the above from useless parts. Thanks, Richard. > > Ciao, > Michael.