From patchwork Thu Jul 20 15:35:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 791662 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-458601-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="jddMsHt7"; dkim-atps=neutral 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 3xCyf42fQTz9s72 for ; Fri, 21 Jul 2017 01:35:34 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=qLsmpDUb2pwBxRaQZ2Gzdy622G8qWs0zI6Xux6frNkv3xL9dQ8V9e l5/UbIcUKMZAD+83PvfrWlwFqE5jEG5zNAJuZo2MZVT5/Z+BBPcw1HQmra44glKl 3Ke0EnS6vkGBjRfFXET92zIrZk3moUucjxew2vMcfeEUta8+q2aj8M= 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 :subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=default; bh=do0s/EZhhrMpQqHTF2QnGM4QEhg=; b=jddMsHt7WbwUI1+dSgNSfzK68hsr McKi5qdWnxqHJCKYAr2hbgwoC3Op/EqXfQrRbsGUmNov+8TThjc9yhILiUKbIzwA c3eEPrnVaEWANDQ5dOsbuKV2eem32tjofeL/1mc3IjGImq7rOzddp4LcnS+3rJ34 AY411RTy2B6D+yY= Received: (qmail 81934 invoked by alias); 20 Jul 2017 15:35:24 -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 81925 invoked by uid 89); 20 Jul 2017 15:35:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3970 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Jul 2017 15:35:21 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-04.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1dYDTy-00071E-I7 from Tom_deVries@mentor.com ; Thu, 20 Jul 2017 08:35:18 -0700 Received: from [127.0.0.1] (137.202.0.87) by SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 16:35:14 +0100 Subject: Re: [PATCH, PR81430] Use finalize_options in lto1 To: Richard Biener CC: GCC Patches , Thomas Schwinge References: <767255ef-911c-d89c-3569-785c30354166@mentor.com> From: Tom de Vries Message-ID: <332f4a94-b737-1a4b-2486-f9cfa6f8aa1e@mentor.com> Date: Thu, 20 Jul 2017 17:35:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) On 07/20/2017 12:10 PM, Richard Biener wrote: > On Thu, 20 Jul 2017, Tom de Vries wrote: > >> Hi, >> >> this patch fixes PR81430, an ICE in the libgomp testsuite for both openmp and >> openacc test-cases for x86_64 with nvptx accelerator. >> >> The scenario how we hit the ICE is as follows: >> - a testcase is compiled with -O2 >> - ix86_option_optimization_table enables >> OPT_freorder_blocks_and_partition at -O2 >> - cc1 writes out the flag as part of DECL_FUNCTION_SPECIFIC_OPTIMIZATION >> - lto1 reads in the flag as part of DECL_FUNCTION_SPECIFIC_OPTIMIZATION >> - lto1 uses the flag, and runs pass_partition_blocks >> - pass_partition_blocks ICEs, because it generates code that is not >> supported by the nvptx target. >> >> Note that for standalone compilation for single-thread ptx execution, we don't >> attempt to run pass_partition_blocks. This is because for nvptx, >> TARGET_HAVE_NAMED_SECTIONS is set to false, and this bit in finish_options >> switches off pass_partition_blocks: >> ... >> /* If the target requested unwind info, then turn off the >> partitioning optimization with a different message. Likewise, if >> the target does not support named sections. */ >> >> if (opts->x_flag_reorder_blocks_and_partition >> && (!targetm_common.have_named_sections >> || (opts->x_flag_unwind_tables >> && targetm_common.unwind_tables_default >> && (ui_except == UI_SJLJ || ui_except >= UI_TARGET)))) >> { >> if (opts_set->x_flag_reorder_blocks_and_partition) >> inform (loc, >> "-freorder-blocks-and-partition does not work " >> "on this architecture"); >> opts->x_flag_reorder_blocks_and_partition = 0; >> opts->x_flag_reorder_blocks = 1; >> } >> ... >> >> The patch fixes this by calling finish_options in lto1 after >> cl_optimization_restore. >> >> Points for review: >> 1. I'm uncertain though about the placement of the call. Perhaps it should be >> in cl_optimization_restore, before targetm.override_options_after_change? >> >> 2. I think that this is offloading specific, so perhaps this should be guarded >> with lto_stream_offload_p or #ifdef ACCEL_COMPILER or some such. > > Hmm, I agree with #2. I think it conceptually is a LTO stream adjustment > and thus we should do this at the time we stream in the > optimization/target nodes (like we remap modes for example). Not > sure if it's possible to do this at that point, but it looks like > finish_options takes two option structs and thus we should be able to > call it. > With what parameters? Patch below tries with same option struct, but ... > Do you get the inform note? I suppose we don't really want that, no? > ... I think that way we'll get the inform note (while the previous solution did not). I've also tried with a tmp2 memset to 0, but that ran into problems when doing a maybe_set_param_value. Thanks, - Tom /* If the file contains a function with an EH personality set, then it was compiled with -fexceptions. In that case, initialize diff --git a/gcc/tree-streamer-in.c b/gcc/tree-streamer-in.c index 7f7ea7f..e0e792b 100644 --- a/gcc/tree-streamer-in.c +++ b/gcc/tree-streamer-in.c @@ -33,6 +33,7 @@ along with GCC; see the file COPYING3. If not see #include "ipa-chkp.h" #include "gomp-constants.h" #include "asan.h" +#include "opts.h" /* Read a STRING_CST from the string table in DATA_IN using input @@ -769,6 +770,20 @@ lto_input_ts_function_decl_tree_pointers (struct lto_input_block *ib, DECL_FUNCTION_SPECIFIC_TARGET (expr) = stream_read_tree (ib, data_in); #endif DECL_FUNCTION_SPECIFIC_OPTIMIZATION (expr) = stream_read_tree (ib, data_in); +#ifdef ACCEL_COMPILER + { + tree opts = DECL_FUNCTION_SPECIFIC_OPTIMIZATION (expr); + if (opts) + { + struct gcc_options tmp; + cl_optimization_restore (&tmp, TREE_OPTIMIZATION (opts)); + finish_options (&tmp, &tmp, DECL_SOURCE_LOCATION (expr)); + opts = build_optimization_node (&tmp); + + DECL_FUNCTION_SPECIFIC_OPTIMIZATION (expr) = opts; + } + } +#endif