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: Richard Guenther <richard dot guenther at gmail dot com>
- To: Jiangning Liu <jiangning dot liu at arm dot com>
- Cc: gcc at gcc dot gnu dot org, Jeff Law <law at redhat dot com>
- Date: Mon, 26 Sep 2011 13:00:45 +0200
- 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>
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?
Thanks,
Richard.
> Thanks,
> -Jiangning
>
>> Richard.
>>
>
>
>
>
>