[PATCH] Fix up ix86_avoid_lea_for_addr (PR target/59880)

H.J. Lu hjl.tools@gmail.com
Thu Jan 23 01:25:00 GMT 2014


On Wed, Jan 22, 2014 at 2:02 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 1:11 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> On Mon, Jan 20, 2014 at 9:38 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>
>>> As mentioned in the PR or even in the comment below, ix86_decompose_address
>>> sometimes sets parts.base to some REG and parts.disp to const0_rtx, even
>>> when the operands aren't of a lea insn, but normal or zero extending mov.
>>>
>>> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>>> trunk?
>>>
>>> 2014-01-20  Jakub Jelinek  <jakub@redhat.com>
>>>
>>>         PR target/59880
>>>         * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false
>>>         if operands[1] is a REG or ZERO_EXTEND of a REG.
>>>
>>>         * gcc.target/i386/pr59880.c: New test.
>>
>>> --- gcc/config/i386/i386.c.jj   2014-01-19 12:18:49.000000000 +0100
>>> +++ gcc/config/i386/i386.c      2014-01-19 19:02:34.078168289 +0100
>>> @@ -18159,8 +18159,19 @@ ix86_avoid_lea_for_addr (rtx insn, rtx o
>>>    if (!TARGET_AVOID_LEA_FOR_ADDR || optimize_function_for_size_p (cfun))
>>>      return false;
>>>
>>> +  /* The "at least two components" test below might not catch simple
>>> +     *mov[sd]i_internal or *zero_extendsidi2 insns if parts.base is
>>> +     non-NULL and parts.disp is const0_rtx as the only components in
>>> +     the address, e.g. if the register is %rbp or %r13.  As this
>>> +     test is much cheaper and moves or zero extensions are the common
>>> +     case, do this check first.  */
>>> +  if (REG_P (operands[1])
>>> +      || (GET_CODE (operands[1]) == ZERO_EXTEND
>>> +         && REG_P (XEXP (operands[1], 0))))
>>> +    return false;
>>> +
>>>    /* Check it is correct to split here.  */
>>> -  if (!ix86_ok_to_clobber_flags(insn))
>>> +  if (!ix86_ok_to_clobber_flags (insn))
>>>      return false;
>>>
>>>    ok = ix86_decompose_address (operands[1], &parts);
>>> --- gcc/testsuite/gcc.target/i386/pr59880.c.jj  2014-01-19 19:24:44.094382629 +0100
>>> +++ gcc/testsuite/gcc.target/i386/pr59880.c     2014-01-19 19:25:30.000000000 +0100
>>> @@ -0,0 +1,14 @@
>>> +/* PR target/59880 */
>>> +/* { dg-do compile { target { ! ia32 } } } */
>>> +/* { dg-options "-O2 -mtune=silvermont" } */
>>> +
>>> +register unsigned int r13 __asm ("r13");
>>> +unsigned long long
>>> +foo (void)
>>> +{
>>> +  return r13;
>>> +}
>>> +
>>> +/* Ensure we don't emit a useless zero-extension after another
>>> +   zero-extension.  */
>>> +/* { dg-final { scan-assembler-not "%eax, %eax" } } */
>>>
>>>         Jakub
>>
>> This is OK for mainline, I will take care for a backport (together
>> with 59379) to other release branches.
>>
>
> I backported gcc.target/i386/pr59880.c to 4.8 branch by
> replacing -mtune=silvermont with -mtune=slm.
>
> Thanks.
>
> --
> H.J.
> --
> Index: ChangeLog
> ===================================================================
> --- ChangeLog (revision 206941)
> +++ ChangeLog (working copy)
> @@ -1,3 +1,11 @@
> +2014-01-22  H.J. Lu  <hongjiu.lu@intel.com>
> +
> + Backport from mainline
> + 2014-01-20  Jakub Jelinek  <jakub@redhat.com>
> +
> + PR target/59880
> + * gcc.target/i386/pr59880.c: New test.
> +
>  2014-01-21  Jakub Jelinek  <jakub@redhat.com>
>
>   PR middle-end/59860
> Index: gcc.target/i386/pr59880.c
> ===================================================================
> --- gcc.target/i386/pr59880.c (revision 0)
> +++ gcc.target/i386/pr59880.c (working copy)
> @@ -0,0 +1,14 @@
> +/* PR target/59880 */
> +/* { dg-do compile { target { ! ia32 } } } */
> +/* { dg-options "-O2 -mtune=slm" } */
> +
> +register unsigned int r13 __asm ("r13");
> +unsigned long long
> +foo (void)
> +{
> +  return r13;
> +}
> +
> +/* Ensure we don't emit a useless zero-extension after another
> +   zero-extension.  */
> +/* { dg-final { scan-assembler-not "%eax, %eax" } } */

I tested it on the wrong branch.  -mtune=slm doesn't exist
on 4.8 branch.   I reverted.  Sorry for it.

-- 
H.J.



More information about the Gcc-patches mailing list