This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Take known zero bits into account when checking extraction.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: vogt at linux dot vnet dot ibm dot com, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Date: Tue, 10 May 2016 12:25:28 +0200
- Subject: Re: [PATCH] Take known zero bits into account when checking extraction.
- Authentication-results: sourceware.org; auth=none
- References: <20160427082004 dot GE5082 at linux dot vnet dot ibm dot com> <394c4136-3642-b3d4-450a-900a76702baa at redhat dot com> <20160509100714 dot GA31298 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1605091533010 dot 11284 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc0DPvVGytO+yokHr-6AjjxF_-77cnnBKwWR_N1S5POMHg at mail dot gmail dot com> <20160510100709 dot GA14601 at linux dot vnet dot ibm dot com>
On Tue, May 10, 2016 at 12:07 PM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> On Tue, May 10, 2016 at 11:14:35AM +0200, Richard Biener wrote:
>> On Mon, May 9, 2016 at 3:36 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>> > On Mon, 9 May 2016, Dominik Vogt wrote:
>> >
>> >> This turns out to be quite difficult. A small test function
>> >> effectively just returns the argument:
>> >>
>> >> unsigned long bar (unsigned long in)
>> >> {
>> >> if ((in & 1) == 0)
>> >> in = (in & ~(unsigned long)1);
>> >>
>> >> return in;
>> >> }
>> >>
>> >> However, Gcc does not notice that the AND is a no-op. As far as I
>> >> understand, zero bit tracking is only done in "combine", so when
>> >> folding the assignment statement the information that the lowest
>> >> bit is zero is not available and therefore the no-op is not
>> >> detected?
>> >
>> >
>> > VRP is also supposed to track bits that may/must be non-zero. It may be
>> > possible to enhance it to handle this case.
>>
>> Actually VRP only tracks value-ranges, CCP tracks may/must be non-zero bits
>> but does not have a conditional lattice.
>
> Does it track known *one* bits too? Because the AND doesn't get
> eliminated here either:
>
> in = in | 3;
> in = in ^ 1;
> in = (in & ~(unsigned long)1);
Yes, but CCP itself does not eliminate this unless something in match.pd
simplifies this (ccp_fold is now simply dispatching there) later. This means
CCP doesn't properly identify the copy here:
Visiting statement:
in_2 = in_1(D) | 3;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x3 (0x0fffffffffffffffc). Adding
SSA edges to worklist.
interesting_ssa_edges: adding SSA use in in_3 = in_2 ^ 1;
marking stmt to be not simulated again
Visiting statement:
in_3 = in_2 ^ 1;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x2 (0x0fffffffffffffffc). Adding
SSA edges to worklist.
interesting_ssa_edges: adding SSA use in in_4 = in_3 & 18446744073709551614;
marking stmt to be not simulated again
Visiting statement:
in_4 = in_3 & 18446744073709551614;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x2 (0x0fffffffffffffffc). Adding
SSA edges to worklist.
interesting_ssa_edges: adding SSA use in _5 = in_4;
marking stmt to be not simulated again
so it only computes new known bits but not whether the operation is
value-preserving.
Richard.
> Ciao
>
> Dominik ^_^ ^_^
>
> --
>
> Dominik Vogt
> IBM Germany
>