From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28421 invoked by alias); 15 Jul 2011 16:07:38 -0000 Received: (qmail 28409 invoked by uid 22791); 15 Jul 2011 16:07:37 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-qy0-f182.google.com (HELO mail-qy0-f182.google.com) (209.85.216.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jul 2011 16:07:22 +0000 Received: by qyk38 with SMTP id 38so846274qyk.20 for ; Fri, 15 Jul 2011 09:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.94 with SMTP id s30mr2790744qch.86.1310746041516; Fri, 15 Jul 2011 09:07:21 -0700 (PDT) Received: by 10.229.71.157 with HTTP; Fri, 15 Jul 2011 09:07:21 -0700 (PDT) In-Reply-To: References: <20110709222042.GA4018@intel.com> Date: Fri, 15 Jul 2011 16:13:00 -0000 Message-ID: Subject: Re: PATCH [5/n] X32: Supprot 32bit address From: "H.J. Lu" To: Uros Bizjak Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg01256.txt.bz2 On Fri, Jul 15, 2011 at 9:01 AM, Uros Bizjak wrote: > On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu wrote: > >>>>>> TARGET_MEM_REF only works on ptr_mode. =A0That means base and index = parts >>>>>> of x86 address operand in x32 mode may be in ptr_mode. =A0This patch >>>>>> supports 32bit base and index parts in x32 mode. =A0OK for trunk? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> H.J. >>>>>> --- >>>>>> 2011-07-09 =A0H.J. Lu =A0 >>>>>> >>>>>> =A0 =A0 =A0 =A0* config/i386/i386.c (ix86_simplify_base_index_disp):= New. >>>>>> =A0 =A0 =A0 =A0(ix86_decompose_address): Support 32bit address in x3= 2 mode. >>>>>> =A0 =A0 =A0 =A0(ix86_legitimate_address_p): Likewise. >>>>>> =A0 =A0 =A0 =A0(ix86_fixup_binary_operands): Likewise. >>>>> >>>>> Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or >>>>> maybe also LEGITIMIZE_RELOAD_ADDRESS) ? >>>>> >>>> >>>> It is because ix86_decompose_address is also called from: >>>> >>>> predicates.md: =A0ok =3D ix86_decompose_address (op, &parts); >>>> predicates.md: =A0ok =3D ix86_decompose_address (op, &parts); >>>> predicates.md: =A0ok =3D ix86_decompose_address (XEXP (op, 0), &parts); >>>> predicates.md: =A0ok =3D ix86_decompose_address (XEXP (op, 0), &parts); >>>> predicates.md: =A0ok =3D ix86_decompose_address (XEXP (op, 0), &parts); >>> >>> Yes, but you should legitimize the address created by reload before it >>> enters into predicates. >>> >>> So, the questions are: >>> >>> + =A0 (set (reg:SI 40 r11) >>> + =A0 =A0 =A0 =A0(plus:SI (plus:SI (mult:SI (reg:SI 1 dx) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(c= onst_int 8)) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (subreg:SI (plus:DI (= reg/f:DI 7 sp) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 (const_int CONST1)) 0)) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(const_int CONST2))) >>> + >>> + =A0 We translate it into >>> + >>> + =A0 (set (reg:SI 40 r11) >>> + =A0 =A0 =A0 =A0(plus:SI (plus:SI (mult:SI (reg:SI 1 dx) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(c= onst_int 8)) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (reg/f:SI 7 sp)) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(const_int [CONST1 + CONST2]))) >>> >>> If the first form of the address is not OK (it does not represent the >>> hardware operation), then it should not enter into the insn stream. >>> This means, that it should be fixed ("legitimized") to second form by >>> appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should >>> fix it, since the incorrect address is generated by IRA/reload). After >>> this operation, various predicates, based on ix86_decompose_address >>> will start to work, since they will decompose valid memory addresses. >>> >> >> IRA/.RELOAD isn't prepared to deal with it and it just ICEs. =A0I opened >> a few GCC bugs on this. >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D47744 >> >> is one of them. =A0That is why I went this route. > > Hm, but it crashed in postreload pass since the address was not in the > legitimate form. =A0This is exactly what LEGITIMIZE_RELOAD_ADDRESS > fixes. Did you try to go this route? > It ran into various ICEs like: /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o m.s -mx32 -std=3D= gnu99 -O2 -fPIC m.i m.i: In function \u2018__kernel_rem_pio2\u2019: m.i:18:1: error: insn does not satisfy its constraints: (insn 108 106 186 3 (set (reg:SI 40 r11 [207]) (plus:SI (plus:SI (mult:SI (reg:SI 1 dx [205]) (const_int 8 [0x8])) (subreg:SI (plus:DI (reg/f:DI 7 sp) (const_int 208 [0xd0])) 0)) (const_int -160 [0xffffffffffffff60]))) m.i:3 251 {*lea_1_x32} (nil)) m.i:18:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:403 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [m.s] Error 1 H.J.