This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 0/3][POPCOUNT]
- From: Jeff Law <law at redhat dot com>
- To: Kugan Vivekanandarajah <kugan dot vivekanandarajah at linaro dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 5 Jul 2018 16:03:11 -0600
- Subject: Re: [PATCH 0/3][POPCOUNT]
- References: <CAELXzTO1FAVbJff1V-RC=a4p6ngw309xM2x7t6LinazKtGtKRg@mail.gmail.com> <firstname.lastname@example.org> <CAELXzTPF5Yqz2oush-VB2DZkoLGSqyk1s7BP9wQ+XN2keFpT=Q@mail.gmail.com>
On 06/24/2018 08:41 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
> Thanks for the comments.
> On 23 June 2018 at 02:06, Jeff Law <email@example.com> wrote:
>> On 06/22/2018 03:11 AM, Kugan Vivekanandarajah wrote:
>>> When we set niter with maybe_zero, currently final_value_relacement
>>> will not happen due to expression_expensive_p not handling. Patch 1
>>> adds this.
>>> With that we have the following optimized gimple.
>>> <bb 2> [local count: 118111601]:
>>> if (b_4(D) != 0)
>>> goto <bb 3>; [89.00%]
>>> goto <bb 4>; [11.00%]
>>> <bb 3> [local count: 105119324]:
>>> _2 = (unsigned long) b_4(D);
>>> _9 = __builtin_popcountl (_2);
>>> c_3 = b_4(D) != 0 ? _9 : 1;
>>> <bb 4> [local count: 118111601]:
>>> # c_12 = PHI <c_3(3), 0(2)>
>>> I assume that 1 in b_4(D) != 0 ? _9 : 1; is OK (?) because when the
>>> latch execute zero times for b_4 == 0 means that the body will execute
>> ISTM that DOM ought to have simplified the conditional, unless there's
>> some other way to get to bb3. We know that b_4 is nonzero and thus c_3
>> must have the value _9.
> As of now, dom is not optimizing it. With the attached hack, it can be made to.
What's strange is I'm not getting the c_3 = (b_4 != 0) ... in any of the
dumps I'm looking at. Instead it's c_3 = _9, which is what I would
expect since we know that b_4 != 0
My tests have been on x86_64 and aarch64 linux targets. I've tried with
patch#1 installed as well as with patch #1 and patch #2 together.
What target, what flags and what patches do I need to see this?