From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17692 invoked by alias); 22 Apr 2015 13:43:17 -0000 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 Received: (qmail 17681 invoked by uid 89); 22 Apr 2015 13:43:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e33.co.us.ibm.com Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 22 Apr 2015 13:43:16 +0000 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Apr 2015 07:43:14 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Apr 2015 07:43:12 -0600 Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 9262A1FF001F for ; Wed, 22 Apr 2015 07:34:22 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3MDfFVT33423436 for ; Wed, 22 Apr 2015 06:41:15 -0700 Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3MDhBhw011636 for ; Wed, 22 Apr 2015 07:43:11 -0600 Received: from [9.65.156.67] (sig-9-65-156-67.ibm.com [9.65.156.67]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t3MDhApw011572; Wed, 22 Apr 2015 07:43:11 -0600 Subject: Re: [PATCH, rs6000, testsuite] Fix PR target/64579, __TM_end __builtin_tend failed to return transactional state From: Peter Bergner To: Segher Boessenkool Cc: GCC Patches , David Edelsohn , Michael Meissner , Bill Schmidt In-Reply-To: <20150422021759.GC23315@gate.crashing.org> References: <1426879660.13627.71.camel@otta> <20150320205200.GA32613@gate.crashing.org> <1426891319.13627.101.camel@otta> <1429649778.21947.25.camel@otta> <20150422021759.GC23315@gate.crashing.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Apr 2015 13:43:00 -0000 Message-ID: <1429710190.21947.48.camel@otta> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15042213-0009-0000-0000-00000A47D223 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01312.txt.bz2 On Tue, 2015-04-21 at 21:17 -0500, Segher Boessenkool wrote: > On Tue, Apr 21, 2015 at 03:56:18PM -0500, Peter Bergner wrote: > > This patch also fixes some issues I hit with the tabortdc[i] and > > htm_m[ft]spr_ patterns when used with -m32 -mpowerpc64. > > Running the testsuite, or did you actually try to _use_ -m32 -mpowerpc64? :-) Not with the testsuite. I had some simple unit tests that basically just returned the CR/SPR and hit some ICEs. > Maybe you can fold tabortdc with tabortwc now? Use one UNSPEC name > for both, :GPR and ? Wouldn't that change the tabortwc pattern to use DImode rather than SImode when compiled with -m64 or -m32 -mpowerpc64? I'm not sure we want that. > > + case HTM_BUILTIN_TTEST: /* Alias for: tabortwci. 0,r0,0 */ > > + op[nopnds++] = GEN_INT (0); > > + op[nopnds++] = gen_rtx_REG (SImode, 0); > > + op[nopnds++] = GEN_INT (0); > > Is that really r0, isn't that (0|rA)? [Too lazy to read the docs myself > right now, sorry.] The ISA doc shows: tabortwci. TO,RA,SI a <- EXTS((RA)32:63) abort <- 0 CR0 <- 0 || MSR(TS) || 0 if a < EXTS(SI) & TO0 then abort <- 1 if a > EXTS(SI) & TO1 then abort <- 1 if a = EXTS(SI) & T02 then abort <- 1 if a u< EXTS(SI) & TO3 then abort <- 1 if a >u EXTS(SI) & TO4 then abort <- 1 ... Given that I'm passing in a zero TO value, the second and third operands are don't care values, so I'm just using r0 and 0 as random input values. I'm only interested in extracting the MSR's Transaction Status (TS) bits and placing them into CR0. > > + emit_insn (gen_movcc (subreg, cr)); > > + emit_insn (gen_lshrsi3 (scratch2, scratch1, GEN_INT (28))); > > + emit_insn (gen_andsi3 (target, scratch2, GEN_INT (0xf))); > > + } > > + } > > Don't we have helper functions/expanders to do these moves? Yuck. Heh, I looked. The only helper pattern was the movcc pattern, but that placed the CR into bits 32-35 of the register. I needed the shift to move it down into the low nibble and I use the "and", since one of the move cr insns places two copies of the CR value into bits 32-35 and 36-39. > > -/* { dg-final { scan-assembler-times "tabortdc\\." 1 } } */ > > -/* { dg-final { scan-assembler-times "tabortdci\\." 1 } } */ > > +/* { dg-final { scan-assembler-times "tabortdc\\." 1 { target lp64 } } } */ > > +/* { dg-final { scan-assembler-times "tabortdci\\." 1 { target lp64 } } } */ > > This skips this test on -m32 -mpowerpc64, is that on purpose? Ummm, not exactly. :-) Not that many people test that though. I'll see if I can find a replacement for lp64 that covers that case. If not, I'm not too torn up if we skip it for -m32 -mpowerpc64. Peter