From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20483 invoked by alias); 21 Sep 2007 08:36:51 -0000 Received: (qmail 20474 invoked by uid 22791); 21 Sep 2007 08:36:50 -0000 X-Spam-Check-By: sourceware.org Received: from hu-out-0506.google.com (HELO hu-out-0506.google.com) (72.14.214.231) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Sep 2007 08:36:48 +0000 Received: by hu-out-0506.google.com with SMTP id 32so293271huf for ; Fri, 21 Sep 2007 01:36:46 -0700 (PDT) Received: by 10.66.255.7 with SMTP id c7mr4191427ugi.1190363805759; Fri, 21 Sep 2007 01:36:45 -0700 (PDT) Received: from scientist.mobile.usilu.net ( [195.176.176.226]) by mx.google.com with ESMTPS id 34sm2349105nfu.2007.09.21.01.36.43 (version=SSLv3 cipher=RC4-MD5); Fri, 21 Sep 2007 01:36:44 -0700 (PDT) Message-ID: <46F3829A.2090305@gnu.org> Date: Fri, 21 Sep 2007 09:38:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Maxim Kuvyrkov CC: Vladimir Makarov , Andrey Belevantsev , gcc-patches Subject: Re: [PATCH] Fix ICE in ia64 speculation support References: <46E97245.5010107@codesourcery.com> <46F2D838.4040309@redhat.com> <46F2DDD6.2040904@redhat.com> <46F37D92.3090206@codesourcery.com> In-Reply-To: <46F37D92.3090206@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-09/txt/msg01663.txt.bz2 > OK, back to the immediate problem: speculative load appears to be trap > risky to the rtl analyzer due to use of (unspec) in its pattern. UNSPEC > is placed into speculative loads to distinguish them from regular ones. > What else, besides UNSPEC, can we use to make insn emit different asm, > but still have the same RTL meaning? I can think of only one > alternative: use a parallel with a nop, e.g., (parallel [(set (reg) > (mem)) (const_int 0)]). I think this is uglier than unspec, plus rtl > analyzers favor parallel less than unspec. I appreciate any advice here. It seems to me that only UNSPEC_VOLATILE is counted as possibly trapping. The problem is than the UNSPEC recurs inside the MEM and that one is marked as trapping. You could add a target hook like unspec_may_trap_p, with a patch like this: Index: rtlanal.c =================================================================== --- rtlanal.c (revision 126191) +++ rtlanal.c (working copy) @@ -2206,8 +2206,11 @@ may_trap_p_1 (rtx x, unsigned flags) case SCRATCH: return 0; - case ASM_INPUT: + case UNSPEC: case UNSPEC_VOLATILE: + return targetm.unspec_may_trap_p (x, flags); + + case ASM_INPUT: case TRAP_IF: return 1; and a default implementation of int j; if (GET_CODE (x) == UNSPEC_VOLATILE) return 1; for (j = 0; j < XVECLEN (x, 0); j++) if (may_trap_p_1 (XVECEXP (x, 0, j), flags)) return 1; The ia64 back-end could special case the unspec like this: if (XINT (x, 1) == ...) return 0; return default_unspec_may_trap_p (x); (Hmm, requires making may_trap_p_1 public, it's static now). Paolo