From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28429 invoked by alias); 31 Oct 2017 15:59:58 -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 27936 invoked by uid 89); 31 Oct 2017 15:59:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SEM_URIRED,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= 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 ESMTP; Tue, 31 Oct 2017 15:59:56 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 84900624C9; Tue, 31 Oct 2017 15:59:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 84900624C9 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-112-29.phx2.redhat.com [10.3.112.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id D77A75D6A3; Tue, 31 Oct 2017 15:59:54 +0000 (UTC) Subject: Re: [PATCH] rs6000: Fix crash with big stack clash interval (PR82674) To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com References: <20171031153258.GB6267@gate.crashing.org> From: Jeff Law Message-ID: <6306e2cf-3e57-150d-8a7b-7a2e6079648a@redhat.com> Date: Tue, 31 Oct 2017 16:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171031153258.GB6267@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg02339.txt.bz2 On 10/31/2017 09:32 AM, Segher Boessenkool wrote: > On Tue, Oct 31, 2017 at 09:12:25AM -0600, Jeff Law wrote: >> On 10/31/2017 03:41 AM, Segher Boessenkool wrote: >>> If the user asks for a stack clash probe interval of 64kB, we currently >>> generate a "stdu rX,-65536(r1)" instruction. That instruction does not >>> exist (the offset is a 16-bit signed number). If the offset is too big >>> we should force it into a register and generate a "stdux rX,rY,r1" >>> instruction, instead. >>> >>> Bootstrapped and regression checked on powerpc64-linux {-m32,-m64}; >>> committing to trunk. >>> >>> >>> Segher >>> >>> >>> 2017-10-31 Segher Boessenkool >>> >>> PR target/82674 >>> * config/rs6000/rs6000.md (allocate_stack): Force update interval >>> into a register if it does not fit into an immediate offset field. >> :-) That's one I had a fix for. But the issues with large probing >> intervals are much more serious. In particular dealing with large >> probing intervals for allocations in the prologue is a significantly >> tougher problem due to the lack of a free hard reg. > > Yes, but I haven't seen testcases for that? The PR was just this. :-) I just turned stack clash on by default, cranked up the probing interval and ran the testsuite and started looking at the root cause of the failures. > > We do have more than one register we can use here, FWIW. It gets a > bit nasty because it depends on which ABI you're on exactly, which. BIg sigh... There are times I wonder if I'd be happier as an app developer or database junkie. Instead I chose to do low level stuff :( jeff