This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix PR middle-end/58570
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 09 Oct 2013 13:36:17 +0200
- Subject: Re: [patch] Fix PR middle-end/58570
- Authentication-results: sourceware.org; auth=none
- References: <18178507 dot ChivVPE93z at polaris> <25150433 dot 2LZFFfBAkC at polaris> <CAFiYyc1ypgAQQWyptdLGPjsgQ6cfFdH8hGc7GydBHXXvsioiUQ at mail dot gmail dot com>
> 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