From patchwork Tue May 14 11:02:55 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 243681 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 60A532C00AF for ; Tue, 14 May 2013 21:03:13 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=pkBzNjntKgiU88XCF yjsjXLFBQwGWPKzr2nLEgyxUGikSp1vkE80zgveA+4Lsv3fKka1thjY+igyNbgdD I1aEVfflQNhek7ov9WldZpDVi8Xe4BTol3txkpR0G2ZaYTDdF5KppsF8Jgjma0KR XKtAd4NkuR25wmsSxY6ZNlvt5w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=bj5oebeif3SNdKAV+q1nw7P jMjQ=; b=efo6qevCfNLQWor5NehU5d7J2Fp8i+zTMi5w8uywnrgsFYWkAcaIlMs XEXXub1HUcaCawknLymg39VrM2ZSXPz2zojJLeiUTxw/hRVwhWhMIDWqOiX51MRJ vrQO1grB8eQ5uNnySKPegNl1hYNsIhVkk+nAgnETxDhliC05az2U= Received: (qmail 2058 invoked by alias); 14 May 2013 11:03:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 2049 invoked by uid 89); 14 May 2013 11:03:06 -0000 X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL, BAYES_00, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS, TW_AV autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 14 May 2013 11:03:06 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4EB33qt009986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 May 2013 07:03:03 -0400 Received: from zalov.cz (vpn-60-24.rdu2.redhat.com [10.10.60.24]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4EB31VI010371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 May 2013 07:03:02 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r4EB2xR4018597; Tue, 14 May 2013 13:03:00 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r4EB2vaW018596; Tue, 14 May 2013 13:02:57 +0200 Date: Tue, 14 May 2013 13:02:55 +0200 From: Jakub Jelinek To: Richard Biener Cc: Uros Bizjak , "H.J. Lu" , Sriraman Tallam , "Joseph S. Myers" , Diego Novillo , GCC Patches , David Li Subject: Re: GCC does not support *mmintrin.h with function specific opts Message-ID: <20130514110255.GP1377@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20130514083913.GJ1377@tucnak.redhat.com> <20130514100419.GM1377@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) On Tue, May 14, 2013 at 12:22:05PM +0200, Richard Biener wrote: > > The problem is that in the first testcase, the VAR_DECL c (guess also b and > > a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector > > types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode > > (it has been laid out while -mno-avx has been the current) and also > > DECL_RTL which is a mem:BLK. Guess expr.c would need to special case > > TREE_STATIC or DECL_EXTERNAL VAR_DECLs with vector type, if they have > > DECL_MODE BLKmode, but TYPE_MODE some vector type, just adjust the MEM > > to the desired mode? fixes the ICE on that testcase. > I think any entity with static storage (maybe even automatic storage) should > have BLKmode (or rather its mode should not matter) and what matters > is the mode we use for the access - that is, the mode of the MEM_REF we > expand, for example. There wasn't any MEM_REF in that case, just SSA_NAME with SSA_NAME_DEF_STMT of a load from VAR_DECL. > That TYPE_MODE is dynamic for vector types is a bad thing. It also means > that type layout may be variable (consider PPC where double has different > alignment in structs, so what layout would a struct with a vector_size(16) > double vector get with -mvsx vs. -mno-vsx?) I haven't introduced the dynamic TYPE_MODE, but getting rid of it would be terribly hard I'm afraid. Anyway, if struct layout depends on modes and handles the vector modes differently from BLKmode, then it is a target bug, it really should look at the types instead. Otherwise if you have such struct in a header, then -mvsx code will be ABI incompatible with -mno-vsx code using the same header. Jakub --- gcc/expr.c.jj 2013-05-14 08:25:40.000000000 +0200 +++ gcc/expr.c 2013-05-14 12:55:46.331983406 +0200 @@ -9310,6 +9310,8 @@ expand_expr_real_1 (tree exp, rtx target set_curr_insn_location (saved_loc); if (REG_P (r) && !REG_EXPR (r)) set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r); + if (MEM_P (r) && GET_MODE (r) == BLKmode && mode != BLKmode) + r = adjust_address (r, mode, 0); return r; }