Hi,
On Wed, 16 Nov 2011, Jeff Law wrote:
> Right. In theory, path isolation would make this optimizable. Make a
> copy of the block containing a[x] = 2 and make it the target when x !=
> 100. At the source level it'd look something like this:
>
> int x;
> extern void f(void);
>
> void g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/16/11 04:00, Richard Guenther wrote:
> On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu
> wrote:
>> Hi,
>>
>> For this test case,
>>
>> int x; extern void f(void);
>>
>> void g(int *a) { a[x] = 1; if (x == 100) f(); a[x] = 2; }
>>
>> For trunk
Hi,
On Wed, 16 Nov 2011, Eric Botcazou wrote:
> > f() may change the value of x, so you cannot optimize away the load on that
> > execution path.
>
> This looks more like an aliasing issue with a, doesn't it?
Correct. There's no call to f() between a[x] and x==100, but the store to
a[x] might
> f() may change the value of x, so you cannot optimize away the load on that
> execution path.
This looks more like an aliasing issue with a, doesn't it?
--
Eric Botcazou
On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu wrote:
> Hi,
>
> For this test case,
>
> int x;
> extern void f(void);
>
> void g(int *a)
> {
> a[x] = 1;
> if (x == 100)
> f();
> a[x] = 2;
> }
>
> For trunk, the x86 assembly code is like below,
>
> movl
From tree dump we can see that there are two assignments from x, one
to unsigned and one to signed. I guess that's the reason. Apparently
there is room to improve though.
int prephitmp.8;
int * D.2027;
unsigned int D.2026;
unsigned int x.1;
int x.0;
# BLOCK 2 freq:1
# PRED: ENTR
