On Wed, Oct 9, 2013 at 1:36 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> In my opinion the MEM_EXPR is "wrong", as it is supposed to be
>> the tree equivalent of the memory access. At gimple level we
>> handle accesses at bit-granularity so bit-accesses are fine.
>> Not so at RTL level it seems.
>>
>> [this also shows we probably should lower bit-granular accesses
>> at the gimple level, as planned for some time (to read, bit-extract
>> and read, bit-modify, write)]
>>
>> Btw, ao_ref_from_mem will AFAIK not correctly handle bit-granular
>> accesses. For
>>
>> struct { int pad : 1; int a : 1; int b : 1; } x;
>>
>> x.a will have MEM_SIZE == 1 and ref->offset = 1, ref->size == 8
>> x.b will have MEM_SIZE == 1 and ref->offset = 2, ref->size == 8
>>
>> so we feed the alias oracle with bit-granular offsets but byte-granular
>> sizes. Now I cannot quickly create a testcase that makes offset
>> based disambiguation disambugate two accesses that overlap
>> with the actual memory access, but I'm not 100% sure it's not
>> possible.
>
> I see, but I'm nevertheless waiting for a testcase.
>
>> While the ultimate solution of making gimple match rtl (byte-granular
>> accesses only) would be best, adjusting the MEM attrs to the
>> RTL land sounds like a more appropriate fix.
>
> This will disable the RTL machinery installed for PR rtl-optimization/44194,
> so we'll need to reopen it... Given that it seems to be working correctly,
> I don't see that point in doing so (and I don't intend to spend time on this
> right now). So let's apply my patchlet first, close PR middle-end/58570 and
> if you want to discuss an alternate plan for PR rtl-optimization/44194, let's
> do that in a separate thread.
Well, ok. Please adjust the comment
+ /* Different fields of the same record type cannot overlap, unless they
+ are both bitfields and we are at the RTL level. */
to sth like
??? Bitfields can overlap at RTL level so punt if we end up at them.
or sth similar. You don't check whether we are at the RTL level after all
(not that this would be appropriate).
Thanks,
Richard.
> --
> Eric Botcazou
