From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-261680-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 11262 invoked by alias); 6 May 2010 07:14:43 -0000
Received: (qmail 11251 invoked by uid 22791); 6 May 2010 07:14:42 -0000
X-SWARE-Spam-Status: No, hits=-1.4 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45
X-Spam-Check-By: sourceware.org
Received: from mail-yw0-f191.google.com (HELO mail-yw0-f191.google.com) (209.85.211.191)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 May 2010 07:14:38 +0000
Received: by ywh29 with SMTP id 29so2941363ywh.14        for <gcc-patches@gcc.gnu.org>; Thu, 06 May 2010 00:14:35 -0700 (PDT)
Received: by 10.101.205.18 with SMTP id h18mr4024458anq.30.1273130075293; Thu, 	06 May 2010 00:14:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.11.3 with HTTP; Thu, 6 May 2010 00:14:15 -0700 (PDT)
In-Reply-To: <201005051458.39945.ebotcazou@adacore.com>
References: <4BDA2513.9000705@codesourcery.com> <201005010054.17350.ebotcazou@adacore.com> 	<4BDE99BF.2030303@codesourcery.com> <201005051458.39945.ebotcazou@adacore.com>
From: Paolo Bonzini <bonzini@gnu.org>
Date: Thu, 06 May 2010 07:14:00 -0000
Message-ID: <m2pf865508f1005060014qa753c0d1n5ddc4cd4e826d2c9@mail.gmail.com>
Subject: Re: Patch: PR40900, extending call patterns
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: Bernd Schmidt <bernds@codesourcery.com>, gcc-patches@gcc.gnu.org, 	Andrew Pinski <pinskia@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2010-05/txt/msg00364.txt.bz2

On Wed, May 5, 2010 at 14:58, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Seems to be because it's a signed operation, and arm has
>>
>> #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) =A0 =A0 \
>> =A0 if (GET_MODE_CLASS (MODE) =3D=3D MODE_INT =A0 =A0 =A0 =A0 \
>> =A0 =A0 =A0 && GET_MODE_SIZE (MODE) < 4) =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> =A0 =A0 { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 \
>> =A0 =A0 =A0 if (MODE =3D=3D QImode) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 \
>> =A0 =A0 =A0 =A0 UNSIGNEDP =3D 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0\
>> =A0 =A0 =A0 else if (MODE =3D=3D HImode) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0\
>> =A0 =A0 =A0 =A0 UNSIGNEDP =3D 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0\
>> =A0 =A0 =A0 (MODE) =3D SImode; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0\
>> =A0 =A0 }
>>
>> while ppc doesn't modify UNSIGNEDP.
>
> Can't we be clever during RTL expansion and avoid blindly zero-extending =
the
> value when we known that
>
> =A0D.2014_1 =3D shortv2 ();
>
> and promote_function_mode sign-extends?

Instead I wonder if ppc optimizes something like

unsigned short short2();

unsigned int int1()
{
  return short2() & 0xFFFF;
}

This would be caught by Bernd's patch too (presumably).

Paolo