From patchwork Tue Dec 6 12:28:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 86797 Delivered-To: patch@linaro.org Received: by 10.182.112.6 with SMTP id im6csp2253844obb; Tue, 6 Dec 2016 04:28:55 -0800 (PST) X-Received: by 10.98.80.140 with SMTP id g12mr62061154pfj.54.1481027335771; Tue, 06 Dec 2016 04:28:55 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id s77si19295290pfa.20.2016.12.06.04.28.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 04:28:55 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-443584-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-443584-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-443584-patch=linaro.org@gcc.gnu.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=T+8WXPScS0Nrr3f+ xh/QFZCw7U7X0Ltmy0z6dJJoN3XuG+Znq+sDlbQJVY+f9VhcWM77hbc7ZIqrtp8S TTnePqo+wnkJRVuHE7UnjopiIdWarQzl7TYYtNOlEkU8q+xDdA7dAuM4bcU9hixX YYMj0s+7YuC0WaKDxud3bgiSGJs= 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 :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=G8Zwe0WAAnHAuinzwUcW18 6BdIc=; b=T8GDHwj6AYEtXF5LAN4/EvyxhkJ5t0BWszDo0uPyNNJLaLqixk85IH dha6TmCoKuhTVyVJn7KARHNUcMLjvmz3rjUPc+X1pnpPH8q5uMhzrNkUWH3OUf0X QZBgNoiYJC6stF4QTmk5jJ9fVbRZzIJFnEv9ev19odB1bASVqpPJk= Received: (qmail 63236 invoked by alias); 6 Dec 2016 12:28:43 -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 63220 invoked by uid 89); 6 Dec 2016 12:28:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=1, 2, 3, 4, SUBREG X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Dec 2016 12:28:32 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 6621C812F4 for ; Tue, 6 Dec 2016 13:28:29 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb-7hStpmD9Q for ; Tue, 6 Dec 2016 13:28:29 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 41948812DB for ; Tue, 6 Dec 2016 13:28:29 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [LRA] Fix ICE on pathological testcase Date: Tue, 06 Dec 2016 13:28:28 +0100 Message-ID: <1651469.y9WBzJujMY@polaris> User-Agent: KMail/4.14.10 (Linux/3.16.7-48-desktop; KDE/4.14.9; x86_64; ; ) MIME-Version: 1.0 Hi, the compiler ICEs for SPARC 64-bit with LRA on the asm-subreg-1.c test: volatile unsigned short _const_32 [4] = {1,2,3,4}; void evas_common_convert_yuv_420p_601_rgba() { __asm__ __volatile__ ("" : : "X" (*_const_32)); } The issue is that combine merges back the 3 instructions necessary to build the address of _const_32 into a big MEM expression: (insn 10 9 0 2 (asm_operands/v ("") ("") 0 [ (mem/v/c:HI (lo_sum:DI (mult:DI (lo_sum:DI (high:DI (unspec:DI [ (symbol_ref:DI ("_const_32") [flags 0x2] ) ] UNSPEC_SETH44)) (unspec:DI [ (symbol_ref:DI ("_const_32") [flags 0x2] ) ] UNSPEC_SETM44)) (const_int 4096 [0x1000])) (symbol_ref:DI ("_const_32") [flags 0x2] )) [1 _const_32+0 S2 A16]) ] [ (asm_input:HI ("X") asm-subreg-1.c:13) ] [] asm-subreg-1.c:13) "asm-subreg-1.c":13 -1 (nil)) and LRA calls decompose_mem_address on the address, which aborts out of confusion; reload (and all subsequent passes) lets it go through unmodified. The attached patch simply adds a bypass to process_address_1 in order to avoid invoking decompose_mem_address in this case. Tested on SPARC/Solaris with LRA and x86-64/Linux, OK for the mainline? 2016-12-06 Eric Botcazou * lra-constraints.c (process_address_1): Do not attempt to decompose addresses for MEMs that satisfy fixed-form constraints. -- Eric Botcazou Index: lra-constraints.c =================================================================== --- lra-constraints.c (revision 243245) +++ lra-constraints.c (working copy) @@ -3080,7 +3080,11 @@ process_address_1 (int nop, bool check_o if (insn_extra_address_constraint (cn)) decompose_lea_address (&ad, curr_id->operand_loc[nop]); - else if (MEM_P (op)) + /* Do not attempt to decompose arbitrary addresses generated by combine + for asm operands with loose constraints, e.g 'X'. */ + else if (MEM_P (op) + && !(get_constraint_type (cn) == CT_FIXED_FORM + && constraint_satisfied_p (op, cn))) decompose_mem_address (&ad, op); else if (GET_CODE (op) == SUBREG && MEM_P (SUBREG_REG (op)))