This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RTL] Add simplify pattern for bitfield insertion
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 5 Nov 2018 10:04:52 -0700
- Subject: Re: [PATCH][RTL] Add simplify pattern for bitfield insertion
- References: <alpine.LSU.2.20.1811051536530.1827@zhemvz.fhfr.qr>
On 11/5/18 7:44 AM, Richard Biener wrote:
>
> The PR18041 testcase is about bitfield insertion of the style
>
> b->bit |= <...>
>
> where the RMW cycle we end up generating contains redundant
> masking and ORing of the original b->bit value. The following
> adds a combine pattern in simplify-rtx to specifically match
>
> (X & C) | ((X | Y) & ~C)
>
> and simplifying that to X | (Y & ~C). That helps improving
> code-generation from
>
> movzbl (%rdi), %eax
> orl %eax, %esi
> andl $-2, %eax
> andl $1, %esi
> orl %esi, %eax
> movb %al, (%rdi)
>
> to
>
> andl $1, %esi
> orb %sil, (%rdi)
>
> if you OR in more state association might break the pattern again.
>
> Still the bug was long-time assigned to me (for doing sth on
> the tree level for combining multiple adjacent bitfield accesses
> as in the original testcase). So this is my shot at the part
> of the problem that isn't going to be solved on trees.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> The "simpler" testcase manages to break the combination on
> x86-64 with -m32, a combine missed-optimization I guess.
>
> A similar case can be made for b->bit &= <...>.
>
> OK for trunk?
>
> Thanks,
> Richard.
>
> 2018-11-05 Richard Biener <rguenther@suse.de>
>
> PR middle-end/18041
> * simplify-rtx.c (simplify_binary_operation_1): Add pattern
> matching bitfield insertion.
>
> * gcc.target/i386/pr18041-1.c: New testcase.
> * gcc.target/i386/pr18041-2.c: Likewise.
There was at least one more BZ in this space (older than 18041).
Essentially all the pieces are there for combine to figure out we've got
a bitfield twiddle, but the the structure of some of combine's code made
it exceedingly hard to exploit. I wonder if this would help. I'm sure
I'll look at it during the stage3/stage4 cycle, so we'll know then.
OK for the trunk. As you note there's likely corresponding cases for
BIT-AND as the toplevel op.
jeff