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.

Reply via email to