From patchwork Wed Aug 27 20:19:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 383545 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 84E05140097 for ; Thu, 28 Aug 2014 06:19:38 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=ucFvx1F9K+25Cpd/S OqcZiyTpQ+OIMgN9efzkOu+pl2Vawkc6eO0xutCRF1fN4drULvfLmuEsttJiBsTE bXFqntFWJ1dV6yu9P86edOUCej1yWl9YacV0jHmXO2zsRlK0vyKV19zoK6K0uyqw bwmfDNtt3Il3ZMMOJtt+3orh7c= 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 :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=kjIesRqsgP6jJUUllL3RXNT 4Eto=; b=D1fupruX9lKJmkXP3k9Es8LoMSN/BTDh1Eu/PgE6LLrlQQK3sz/1hbW gwWvXnFc1q0dTKamL+xDSnDmYuv2zEKEKmcn/o+2J4oDg5JBSAEXi6qq3h29Z3rF J1HTBkQMMp5BHX/Cp/ZHrGEf9PrlF+814fxpeXWcEXH0hD40xXQA= Received: (qmail 8028 invoked by alias); 27 Aug 2014 20:19:29 -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 8016 invoked by uid 89); 27 Aug 2014 20:19:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_50, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 27 Aug 2014 20:19:26 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7RKJPjN001334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Aug 2014 16:19:25 -0400 Received: from VMBP.local (vpn-62-233.rdu2.redhat.com [10.10.62.233]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7RKJNBN021768; Wed, 27 Aug 2014 16:19:23 -0400 Message-ID: <53FE3D46.8050904@redhat.com> Date: Wed, 27 Aug 2014 16:19:18 -0400 From: Vladimir Makarov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ilya Enkovich CC: gcc@gnu.org, gcc-patches , Evgeny Stupachenko , Richard Biener , Uros Bizjak , Jeff Law Subject: Re: Enable EBX for x86 in 32bits PIC code References: <20140707114750.GB31640@tucnak.redhat.com> <20140822121151.GA60032@msticlxl57.ims.intel.com> <53FB5184.3030500@redhat.com> <53FCA6F5.7020405@redhat.com> <20140826213712.GA39451@msticlxl57.ims.intel.com> In-Reply-To: <20140826213712.GA39451@msticlxl57.ims.intel.com> X-IsSubscribed: yes On 2014-08-26 5:42 PM, Ilya Enkovich wrote: > Hi, > > Here is a patch I tried. I apply it over revision 214215. Unfortunately I do not have a small reproducer but the problem can be easily reproduced on SPEC2000 benchmark 175.vpr. The problem is in read_arch.c:701 where float value is compared with float constant 1.0. It is inlined into read_arch function and can be easily found in RTL dump of function read_arch as a float comparison with 1.0 after the first call to strtod function. > > Here is a compilation string I use: > > gcc -m32 -mno-movbe -g3 -fdump-rtl-all-details -O2 -ffast-math -mfpmath=sse -m32 -march=slm -fPIE -pie -c -o read_arch.o -DSPEC_CPU2000 read_arch.c > > In my final assembler comparison with 1.0 looks like: > > comiss .LC11@GOTOFF(%ebp), %xmm0 # 1101 *cmpisf_sse [length = 7] > > and %ebp here doesn't have a proper value. > > I'll try to make a smaller reproducer if these instructions don't help. I've managed to reproduce it. Although it would be better to send the patch as an attachment. The problem is actually in IRA not LRA. IRA splits pseudo used for PIC. Then in a region when a *new* pseudo used as PIC we rematerialize a constant which transformed in memory addressed through *original* PIC pseudo. To solve the problem we should prevent such splitting and guarantee that PIC pseudo allocnos in different region gets the same hard reg. The following patch should solve the problem. Index: ira-color.c =================================================================== --- ira-color.c (revision 214576) +++ ira-color.c (working copy) @@ -3239,9 +3239,10 @@ ira_assert (ALLOCNO_CLASS (subloop_allocno) == rclass); ira_assert (bitmap_bit_p (subloop_node->all_allocnos, ALLOCNO_NUM (subloop_allocno))); - if ((flag_ira_region == IRA_REGION_MIXED) - && (loop_tree_node->reg_pressure[pclass] - <= ira_class_hard_regs_num[pclass])) + if ((flag_ira_region == IRA_REGION_MIXED + && (loop_tree_node->reg_pressure[pclass] + <= ira_class_hard_regs_num[pclass])) + || regno == (int) REGNO (pic_offset_table_rtx)) { if (! ALLOCNO_ASSIGNED_P (subloop_allocno)) { Index: ira-emit.c =================================================================== --- ira-emit.c (revision 214576) +++ ira-emit.c (working copy) @@ -620,7 +620,8 @@ /* don't create copies because reload can spill an allocno set by copy although the allocno will not get memory slot. */ - || ira_equiv_no_lvalue_p (regno))) + || ira_equiv_no_lvalue_p (regno) + || ALLOCNO_REGNO (allocno) == REGNO (pic_offset_table_rtx))) continue; original_reg = allocno_emit_reg (allocno); if (parent_allocno == NULL