From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78197 invoked by alias); 4 May 2015 16:38:45 -0000 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 Received: (qmail 78168 invoked by uid 89); 4 May 2015 16:38:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: smtp.ispras.ru Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.199.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 May 2015 16:38:44 +0000 Received: from condor.intra.ispras.ru (unknown [83.149.199.91]) by smtp.ispras.ru (Postfix) with ESMTP id 270E2214F1; Mon, 4 May 2015 19:38:42 +0300 (MSK) Received: by condor.intra.ispras.ru (Postfix, from userid 23246) id 205351227575; Mon, 4 May 2015 19:38:42 +0300 (MSK) From: Alexander Monakov To: gcc-patches@gcc.gnu.org Cc: Alexander Monakov , Rich Felker Subject: [RFC PATCH] ira: accept loads via argp rtx in validate_equiv_mem Date: Mon, 04 May 2015 16:38:00 -0000 Message-Id: <1430757479-14241-7-git-send-email-amonakov@ispras.ru> In-Reply-To: <1430757479-14241-1-git-send-email-amonakov@ispras.ru> References: <1430757479-14241-1-git-send-email-amonakov@ispras.ru> X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00229.txt.bz2 With this patch at hand, I'd like to discuss a code generation problem, which my patch solves only partially. FWIW, it passes bootstrap/regtest on x86-64. With other patches in series applied, GCC with -fno-plt can generate tail calls in PIC mode more frequently, but sometimes poorer code is generated. I've tried to look for possible causes, and found one issue so far. Consider the following testcase: void foo1(int a, int b, int c, int d, int e, int f, int g, int h); int bar(int x); void foo2(int a, int b, int c, int d, int e, int f, int g, int h) { bar(a); foo1(a, b, c, d, e, f, g, h); } Comparing x86 code generation with -O2 -m32 and with/without -fPIC, you can see that -fPIC happens to produce smaller code. Without -fPIC, GCC saves/restores all arguments before/after call to 'bar'. The reason for that is without -fPIC, GCC performs tail call optimization on 'foo1', and that causes it to drop REG_EQUIV notes for incoming arguments in fixup_tail_calls. After that, code generation diverges at IRA stage, where lack of equivalences prevents loads of pseudos to be moved to the point of first use. The patch tries to repair the problem by allowing REG_EQUIV notes to be resynthesized at ira init for loads that happen via `argp' rtx. It helps for the simple testcase above, but not for problematic Clang/LLVM functions where I noticed the issue. I hope there's a way around the 'big hammer' approach of fixup_tail_calls. Might it be possible instead of dropping REG_EQUIV notes, to copy incoming arguments into other pseudos just prior to stack pointer adjustment in preparation for tailcall? diff --git a/gcc/ira.c b/gcc/ira.c index ea2b69f..e6b82e2 100644 --- a/gcc/ira.c +++ b/gcc/ira.c @@ -3001,13 +3001,16 @@ validate_equiv_mem (rtx_insn *start, rtx reg, rtx memref) /* This used to ignore readonly memory and const/pure calls. The problem is the equivalent form may reference a pseudo which gets assigned a call clobbered hard reg. When we later replace REG with its equivalent form, the value in the call-clobbered reg has been changed and all hell breaks loose. */ - if (CALL_P (insn)) + rtx addr = XEXP (memref, 0); + if (GET_CODE (addr) == PLUS && GET_CODE (XEXP (addr, 1)) == CONST_INT) + addr = XEXP (addr, 0); + if (CALL_P (insn) && addr != arg_pointer_rtx) return 0; note_stores (PATTERN (insn), validate_equiv_mem_from_store, NULL); /* If a register mentioned in MEMREF is modified via an auto-increment, we lose the equivalence. Do the same if one