This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A case that PRE optimization hurts performance
- From: Jeff Law <law at redhat dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Jiangning Liu <jiangning dot liu at arm dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 26 Sep 2011 10:42:56 -0600
- Subject: Re: A case that PRE optimization hurts performance
- References: <4e3762ed.030d440a.1143.2af2SMTPIN_ADDED@mx.google.com> <CAFiYyc0KyF4unL8hurQ77=rArSrxonFzz_MGKZDLZ=rSYZ__DQ@mail.gmail.com> <4e72add8.c9d0e30a.142a.ffffe60eSMTPIN_ADDED@mx.google.com> <CAFiYyc0dfbp_qJCueUj-aNKfF4=8SxshE7_eDZED9i1DF5GNwg@mail.gmail.com> <4e802c3d.94ebd80a.4b1f.ffff8101SMTPIN_ADDED@mx.google.com> <CAFiYyc20iUN7ecR_4W=NC1j1cGcRhKaLGs-VCqmBH9zu0F3iCg@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/26/11 05:00, Richard Guenther wrote:
> On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu
> <jiangning.liu@arm.com> wrote:
>>>> * Without PRE,
>>>>
>>>> Path1: movl $2, %eax cmpl $1, %eax je .L3
>>>>
>>>> Path2: movb $3, %al cmpl $1, %eax je .L3
>>>>
>>>> Path3: cmpl $1, %eax jne .L14
>>>>
>>>> * With PRE,
>>>>
>>>> Path1: movl $1, %ebx movl $2, %eax testb %bl, %bl je
>>>> .L3
>>>>
>>>> Path2: movl $1, %ebx movb $3, %al testb %bl, %bl je
>>>> .L3
>>>>
>>>> Path3: cmpl $1, %eax setne %bl testb %bl, %bl jne
>>>> .L14
>>>>
>>>> Do you have any more thoughts?
>>>
>>> It seems to me that with PRE all the testb %bl, %bl should be
>>> evaluated at compile-time considering the preceeding movl $1,
>>> %ebx. Am I missing something?
>>>
>>
>> Yes. Can this be done by PRE or any other optimizations in middle
>> end?
>
> Hm, the paths as you quote them are obfuscated by missed
> jump-threading. On the tree level we have
>
> # s_2 = PHI <2(5), 3(4), 2(6), s_25(7)> # prephitmp.6_1 = PHI
> <1(5), 1(4), 1(6), prephitmp.6_3(7)> <L10>: t_14 = t_24 + 1;
> D.2729_6 = MEM[base: t_14, offset: 0B]; D.2732_7 = D.2729_6 != 0;
> D.2734_9 = prephitmp.6_1 & D.2732_7; if (D.2734_9 != 0)
>
> where we could thread the cases with prephitmp.6_1 == 1,
> ultimately removing the & and forwarding the D.2729_6 != 0 test.
> Which would of course cause some code duplication.
>
> Jeff, you recently looked at tree jump-threading, can you see if
> we can improve things on this particular testcase?
There's nothing threading can do here because it doesn't know anything
about the value MEM[t14].
Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOgKuLAAoJEBRtltQi2kC75aIH/iikuOQXrMrQJFbQw0COXznB
OGq8iXdGwTJGH13vxdItTE0upJp7RgUVLzuhdqj1elTLHv/ujYygMsQRNGKcc8tb
GMLECmWDhZqQTFXcTJCgJNZiv7MH1PNELXSdIkkSnxY+pwyn9AX5D3+HcTSjGU6B
51AdUNVph/VSaVboAgcrFpu9S0pX9HVTqFy4JI83Lh613zDVSmPo14DDy7vjBvE9
2Srlvlw0srYup97bGmRqN8wT4ZLLlyYSB2rjEFc6jmgXVncxiteQYIUZpy0lcC0M
q3j80aXjZ57/iWyAbqDr1jI5tbVKDBkRa9LL1jvn9534adiG4GrnSMPhoog0ibA=
=azr5
-----END PGP SIGNATURE-----