From patchwork Sat Dec 8 18:13:45 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xinliang David Li X-Patchwork-Id: 204674 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]) by ozlabs.org (Postfix) with SMTP id 34AB52C0209 for ; Sun, 9 Dec 2012 05:14:01 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1355595243; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:Date:Message-ID:Subject:From:To: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=oQiFRuB PdNFrBJ10pnWpIdjpyI0=; b=RKii9aBs4miupb1cOYaqOOAeaEaJDqIktLKy0ko 0vd0ai8IUnB0IjjWqyDl4baYXpZGWNRqCNBPUhLiYg+B35UY9rLzZs8xt565ZT+5 K0YjYbSu1Y60b+hQDXrVrPS2CW4tmac+ZVh4oYu3xPvQ86t0lCBIADdfs/7NLfRH Hpig= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:X-Google-DKIM-Signature:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Content-Type:X-Gm-Message-State:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=xOVMfCY7apx51F56jlSPWzCjIvsbuoFDmleRJdEUazqCbUC5jWqKhVDdpY1URI txIBlLrNfGDUkjRfHSkj3vaQvhgsMiln5/RvD3gvHgC3N2qS7Ec5OD5TBZzLT4gz DHyeVeD/TuzvTkpidf8o4qLaY8MTbSXUtyrSnebn4f6Jc=; Received: (qmail 17161 invoked by alias); 8 Dec 2012 18:13:54 -0000 Received: (qmail 17151 invoked by uid 22791); 8 Dec 2012 18:13:53 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 08 Dec 2012 18:13:47 +0000 Received: by mail-wg0-f53.google.com with SMTP id ei8so705270wgb.8 for ; Sat, 08 Dec 2012 10:13:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=Rm/y4pny7Lhxb/og5U2nZHDmt05Ol4RkodYJbZgqfvg=; b=Yta40z5XerTEU/L0fKjCvISnqc0dQFRWYa5PkNzVFZxcxlTGwTQRI+xcbzjdA/RLTa C/IL1NqAC7Ir0Y75ZHFk38OiIdXznFpS3E5JdV9jx4tGdoclorqgBLkOI+A5ckJsoYea q0hewr4b0TmaFMHcnSeKonIedD2naFD0Q0iW/4ayTf9Whzd+sVyYlC7c42RQUaDPij7T zizAFfePjx4gijwUD4RU/Vv0+TJHYdhrCbaAWHFqk2yPv4U8picAR1Qp9M+kOnbs4rU0 R7FTsoJvFwLQEtRmiUAHexbRPfV5kWzD3BvMIDJTEChvaoOIXYtaIRK/9V9FigLGpMDd fAVw== MIME-Version: 1.0 Received: by 10.216.213.170 with SMTP id a42mr3045317wep.71.1354990425619; Sat, 08 Dec 2012 10:13:45 -0800 (PST) Received: by 10.216.190.207 with HTTP; Sat, 8 Dec 2012 10:13:45 -0800 (PST) Date: Sat, 8 Dec 2012 10:13:45 -0800 Message-ID: Subject: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs From: Xinliang David Li To: GCC Patches X-Gm-Message-State: ALoCoQlUpg0P2ygkPBaG9eWIOaU29e707emV+aaSdRgn3q6KWfANZJlxoPOW2NQQGefav4UkJjk5WKPObLoQgb8jYvVPjdTvQcl2SkkUOWLESkNgVRWQHFEDsnLpXzsDS9jmxJK/xU+dWUquE5A8X7xruzW2VQfPUz7KQkQvH5dQYSTDUZUEZMysAeFwaEt3+eGkAk9WNnID X-IsSubscribed: yes 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 I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a SP adjustment instead of a sequence of pushes/pops. The preference to the MOVs are good for old CPU micro-architectures (before pentium-4, K10), because it breaks the data dependency. In modern micro-architecture, push/pop is implemented using a mechanism called stack engine. The data dependency is removed by the hardware, and push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are smaller. There is no longer the need to avoid using them. This is also what ICC does. The following patch fixed the problem. It passes bootstrap/regression test. OK to install? thanks, David 2012-12-08 Xinliang David Li * config/i386/i386.c: Eanble push/pop in pro/epilogue for moderen CPUs. Index: config/i386/i386.c =================================================================== --- config/i386/i386.c (revision 194324) +++ config/i386/i386.c (working copy) @@ -1919,10 +1919,10 @@ static unsigned int initial_ix86_tune_fe m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMD_MULTIPLE | m_GENERIC, /* X86_TUNE_PROLOGUE_USING_MOVE */ - m_PPRO | m_CORE2I7 | m_ATOM | m_ATHLON_K8 | m_GENERIC, + m_PPRO | m_ATHLON_K8, /* X86_TUNE_EPILOGUE_USING_MOVE */ - m_PPRO | m_CORE2I7 | m_ATOM | m_ATHLON_K8 | m_GENERIC, + m_PPRO | m_ATHLON_K8, /* X86_TUNE_SHIFT1 */ ~m_486,