From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7647 invoked by alias); 1 Jul 2011 16:38:02 -0000 Received: (qmail 7440 invoked by uid 22791); 1 Jul 2011 16:37:59 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Jul 2011 16:37:45 +0000 Received: by wyg30 with SMTP id 30so2805950wyg.20 for ; Fri, 01 Jul 2011 09:37:43 -0700 (PDT) Received: by 10.227.57.130 with SMTP id c2mr3053430wbh.68.1309538263363; Fri, 01 Jul 2011 09:37:43 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id gb1sm2468412wbb.37.2011.07.01.09.37.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 09:37:42 -0700 (PDT) From: Richard Sandiford To: "H.J. Lu" Mail-Followup-To: "H.J. Lu" ,gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc-patches@gcc.gnu.org Subject: Re: PATCH [2/n]: Prepare x32: Convert pointer to TLS symbol if needed References: <20110611154235.GA19926@intel.com> Date: Fri, 01 Jul 2011 16:38:00 -0000 In-Reply-To: (H. J. Lu's message of "Wed, 29 Jun 2011 09:25:39 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00058.txt.bz2 "H.J. Lu" writes: > On Wed, Jun 29, 2011 at 7:06 AM, H.J. Lu wrote: >> On Wed, Jun 29, 2011 at 1:45 AM, Richard Sandiford >> wrote: >>> "H.J. Lu" writes: >>>> @@ -706,7 +706,13 @@ precompute_register_parameters (int num_actuals, = struct arg_data *args, >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pseudo now. =C2=A0TLS symbols someti= mes need a call to resolve. =C2=A0*/ >>>> =C2=A0 =C2=A0 =C2=A0 if (CONSTANT_P (args[i].value) >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 && !targetm.legitimate_constant_p (= args[i].mode, args[i].value)) >>>> - =C2=A0 =C2=A0 =C2=A0 args[i].value =3D force_reg (args[i].mode, args= [i].value); >>>> + =C2=A0 =C2=A0 =C2=A0 { >>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (GET_MODE (args[i].value) !=3D args[i= ].mode) >>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 args[i].value =3D convert_to_mode= (args[i].mode, >>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0args[i].value, >>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0args[i].unsignedp); >>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 args[i].value =3D force_reg (args[i].mod= e, args[i].value); >>>> + =C2=A0 =C2=A0 =C2=A0 } >>> >>> But if GET_MODE (args[i].value) !=3D args[i].mode, then the call to >>> targetm.legitimate_constant_p looks wrong. =C2=A0The mode passed in the >>> first argument is supposed to the mode of the second argument. >>> >>> Is there any reason why this and the following: >>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0/* If we are to promote the function arg to = a wider mode, >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 do it now. =C2=A0*/ >>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (args[i].mode !=3D TYPE_MODE (TREE_TYPE (= args[i].tree_value))) >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0args[i].value >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D convert_modes (args[i].mod= e, >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 TYPE_MODE (TREE_TYPE (args[i].tree_value)), >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 args[i].value, args[i].unsignedp); >>> >>> need to be done in the current order? =C2=A0I can't think of any off-ha= nd. >>> If not, would swapping them also fix the bug? >>> >>> (I can't review this either way, of course.) >> >> It works on the testcase. =C2=A0I will do a full test. >> > > It works. There are no regressions on Linux/x86-64. Great! I can't approve it, but FWIW, it looks good to me. The new order seems to make more conceptual sense: coerce the value into the right mode, then coerce it into the right type of rtx. Richard