This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix PR middle-end/58570


> 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.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]