This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Improve andq $0xffffffff, %reg handling (PR target/53110)
- From: Teresa Johnson <tejohnson at google dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, David Li <davidxl at google dot com>
- Date: Mon, 23 Jul 2012 13:17:06 -0700
- Subject: Re: [PATCH] Improve andq $0xffffffff, %reg handling (PR target/53110)
- References: <20120425191453.GX16117@tyan-ft48-01.lab.bos.redhat.com> <CAFULd4Zf6MSEmY_jF5ppWBY+Wz5Jwou3w-kS1jGdEXpwNxubcg@mail.gmail.com> <20120426152814.GB16117@tyan-ft48-01.lab.bos.redhat.com> <CAFULd4ZKBD_OzR7DFT2RogTW8B4gavRXbgxXs44i-X2viz-5HQ@mail.gmail.com> <CAFULd4aXx3Lbweow+5FoFeHA-3ud2r-6ckz7XEzK3jWazvG18A@mail.gmail.com> <20120430131009.GK16117@tyan-ft48-01.lab.bos.redhat.com> <CAFULd4ZEe1WW2cgd7_ENoF-BviuOH65ArX1nFqP9e0SyxiQs3w@mail.gmail.com> <CAAe5K+V=fycJ5Fxc0i=SHtfmhtYdETfYjjA6UzFe=15YiCbQhA@mail.gmail.com>
Resending in plain text mode so it goes through.
Teresa
On Mon, Jul 23, 2012 at 12:03 PM, Teresa Johnson <tejohnson@google.com> wrote:
> Any possibility of getting these patches (186979 and 186993), along with
> r184891 (which added the and->zext splitter), backported to the 4_7 branch?
> I found a performance issue where "andw $0xff, %reg" was not being converted
> to movzbl when the source and target registers are the same, resulting in
> LCP stalls, which is fixed by this series of patches.
>
> Thanks,
> Teresa
>
>
> On Mon, Apr 30, 2012 at 10:14 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>
>> On Mon, Apr 30, 2012 at 3:10 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Mon, Apr 30, 2012 at 02:54:05PM +0200, Uros Bizjak wrote:
>> >> > My recent changes to zero_extend expanders should handle this
>> >> > automatically, and will undo generation of zero_extend pattern.
>> >> > Please
>> >> > see zero_extend<mode>si2_and expander, and how it handles
>> >> > TARGET_ZERO_EXTEND_WITH_AND targets.
>> >>
>> >> Attached patch implements this idea. In addition, it fixes the
>> >> splitter to not change output mode of zero_extension from HImode and
>> >> QImode from DImode to SImode. Although they generate the same
>> >> instruction, I think we should better keep original mode here.
>> >
>> > Thanks. I was trying this morning slightly different patch for the
>> > same,
>> > but strangely it failed bootstrap, and didn't get around to analysing
>> > why a mem store had (zero_extend (subreg (reg))) on a RHS.
>> >
>> >> + operands[1] = gen_lowpart (mode, operands[1]);
>> >> +
>> >> + if (GET_MODE (operands[0]) == DImode)
>> >> + insn = (mode == SImode)
>> >> + ? gen_zero_extendsidi2
>> >> + : (mode == HImode)
>> >> + ? gen_zero_extendhidi2
>> >> + : gen_zero_extendqidi2;
>> >> + else if (GET_MODE (operands[0]) == SImode)
>> >> + insn = (mode == HImode)
>> >> + ? gen_zero_extendhisi2
>> >> + : gen_zero_extendqisi2;
>> >> + else if (GET_MODE (operands[0]) == HImode)
>> >> + insn = gen_zero_extendqihi2;
>> >> else
>> >> - ix86_expand_binary_operator (AND, <MODE>mode, operands);
>> >> + gcc_unreachable ();
>> >> +
>> >> + emit_insn (insn (operands[0], operands[1]));
>> >
>> > IMHO you should use <MODE>mode instead of GET_MODE (operands[0])
>> > in all of the above, then the compiler can actually optimize
>> > it at compile time.
>>
>> 2012-04-30 Uros Bizjak <ubizjak@gmail.com>
>>
>> * config/i386/i386.md (and<mode>3): Change runtime operand mode
>> checks
>> to compile-time "mode == <MODE>mode" checks.
>> (and splitter): Ditto.
>>
>> Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
>>
>> Uros.
>
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413
>
--
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413