From patchwork Tue Dec 15 15:09:56 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Bruel X-Patchwork-Id: 556992 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id D953C1402C9 for ; Wed, 16 Dec 2015 02:10:27 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=t6/VH+tB; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:message-id:date:mime-version:content-type; q=dns; s= default; b=QY5f8T5BYk5BnLAvg2DQJZvQbEZYOdzrFax9NerCry+mjuvcPH0Oy vSDeq/4mp3T3QFau9gDVuwSq49ZYj7LgqNkLsCpN2rS1PiyuwrY9TMzKQebp852K 6f7I2ai6okzrGY7FL4aNtM9T/YzYIDtFQm91PGmlpdGiCOy66/U/tA= 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:from :subject:to:message-id:date:mime-version:content-type; s= default; bh=CBVlODD9Ae1xwbdliHZ2TwGNqmI=; b=t6/VH+tB5eoMAjlhIDJK fto6IQx77ZGoi27s94MJY6Fr0BoyxRbHEpoIqnf003/i3huZcgWimmPdawpdtb7m li1UhkIbTWLrD1ktu8gn48oho4K7bs+5hELi3hvpTst56sq28G09jTHyDP0de/PY X/XdCD2WF/PIMKaPTttBMlc= Received: (qmail 63041 invoked by alias); 15 Dec 2015 15:10:18 -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 63016 invoked by uid 89); 15 Dec 2015 15:10:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mx07-00178001.pphosted.com Received: from mx08-00178001.pphosted.com (HELO mx07-00178001.pphosted.com) (91.207.212.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 15 Dec 2015 15:10:03 +0000 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.14.5/8.14.5) with SMTP id tBFEna3N000762 for ; Tue, 15 Dec 2015 16:09:59 +0100 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 1yth4y99wu-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 15 Dec 2015 16:09:59 +0100 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A37EB3D for ; Tue, 15 Dec 2015 15:09:20 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas4.st.com [10.75.90.69]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A285FA50F for ; Tue, 15 Dec 2015 15:09:57 +0000 (GMT) Received: from [164.129.122.197] (164.129.122.197) by webmail-eu.st.com (10.75.90.13) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 15 Dec 2015 16:09:57 +0100 From: Christian Bruel Subject: [PATCH][LTO,ARM] Fix vector TYPE_MODE in streaming-out To: X-No-Archive: yes Message-ID: <56702D44.1010103@st.com> Date: Tue, 15 Dec 2015 16:09:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-15_07:2015-12-15, 2015-12-15, 1970-01-01 signatures=0 X-IsSubscribed: yes Hello, This patch fixes a few ICEs that I'm having while enabling the ARM/NEON builtins for LTO (in a parallel development line, so the testcase is cannot work in isolation but should illustrate the problem) For instance, the global declarations in the following code compiled with -mfpu=neon ---------------------------------- __simd64_int8_t a; __simd128_int16_t e; int main() { e = __builtin_neon_vaddlsv8qi (a, a); return 0; } ---------------------------------- in "normal" mode, the TYPE_MODE for vector_type __simd64_int8_t is set to V8QImode by arm_vector_mode_supported_p during the builtins type initializations, thanks to TARGET_NEON set bu the global flag. Now, in LTO mode the streamer writes the information for this vector_type as a scalar DImode, causing ICEs during arm_expand_builtin. The root cause of this is that the streamer-out uses TYPE_MODE in a context where the target_flags are not known return false for TARGET_NEON. The streamer-in then will then read the wrong mode that propagates to the back-end. Using the value computed by the middle end (when the current target was known) in type_common.mode instead of calling vector_type_mode during the LTO streaming fixes this issue. Does that seem all-right to skip vector_type_mode dynamic machinery in the lto streamer since the streamer should not change modes used by the middle-end (I assume) ? comments ? many thanks Christian (for ref: this is a follow-up of https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01094.html) Index: tree-streamer-out.c =================================================================== --- tree-streamer-out.c (revision 231644) +++ tree-streamer-out.c (working copy) @@ -308,7 +308,7 @@ pack_ts_function_decl_value_fields (stru static void pack_ts_type_common_value_fields (struct bitpack_d *bp, tree expr) { - bp_pack_machine_mode (bp, TYPE_MODE (expr)); + bp_pack_machine_mode (bp, expr->type_common.mode); bp_pack_value (bp, TYPE_STRING_FLAG (expr), 1); /* TYPE_NO_FORCE_BLK is private to stor-layout and need no streaming. */