From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 6C3D0385842E for ; Thu, 19 Aug 2021 15:03:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6C3D0385842E Received: by mail-qk1-x733.google.com with SMTP id 14so7466549qkc.4 for ; Thu, 19 Aug 2021 08:03:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=u/+2pVHcIbuiIPAKlmFWJv5k+5JUZnxNYEvAHUSXokQ=; b=Ywx1VqQ58+tnbWA2vjVw7uZvl34/IJmULwmry3H998uvYbtJRzCUJKKi1Kkouiv5OV 8n4As9dav0lpGiAjEyThkBOXJIo49a3muXHbc08xhSirq1l661HTTzE/YOvtpiyrXlST UCpYNjqLdgC949QlOMAKenchHHnRvNqH7lqCuJTpZMC2uN5kew4ikj1eFq3oCGI9+b4z DpFiESlddc1gDKVsv0HwVHNrEMv9QBDCnVKLdp2rt/IjX8PppYEGuB/ztzLLI8I7SI3c jyanmpZkbPLBa0FyIWFb5mVO5wuhcSbEMduarqeSeG52DHEDnmAfvPe53lkgG0x6dUPy 4Lvg== X-Gm-Message-State: AOAM530toV1Nge1Ax+ptMx21rb4UNLDoRbOAFe89/IetrC9pWKYO8K2t iyXlANgODuSMQ+S2PeIZs4BWX8onZXE= X-Google-Smtp-Source: ABdhPJzqtUTnH7IZZigIbhNLt8RqyD0a9DqNDasJ8BDjG3HlXDyq70ubunEMOWAg3qIBshGFm0yQ2A== X-Received: by 2002:a37:6255:: with SMTP id w82mr4046786qkb.252.1629385426698; Thu, 19 Aug 2021 08:03:46 -0700 (PDT) Received: from [192.168.0.41] (97-118-104-61.hlrn.qwest.net. [97.118.104.61]) by smtp.gmail.com with ESMTPSA id h13sm1678701qkk.67.2021.08.19.08.03.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 08:03:46 -0700 (PDT) Subject: Re: [PATCH] more warning code refactoring To: "Kewen.Lin" , David Edelsohn Cc: GCC Patches References: From: Martin Sebor Message-ID: <768a1662-ec8a-d714-1982-d776d3ae6583@gmail.com> Date: Thu, 19 Aug 2021 09:03:44 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 15:03:57 -0000 On 8/18/21 11:56 PM, Kewen.Lin wrote: > Hi David, > > on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote: >> Hi, Martin >> >> A few PowerPC-specific testcases started failing yesterday on AIX with >> a strange failure mode: the compiler runs out of memory. As you may >> expect from telling you this in an email reply to your patch, I have >> bisected the failure and landed on your commit. I can alternate >> between the previous commit and your commit, and the failure >> definitely appears with your patch, although I'm unsure how your patch >> affected memory allocation in the compiler. Maybe moving the code >> changed a type of allocation or some memory no longer is being freed? >> > > > To get rid of GTY variable alloc_object_size_limit looks suspicious, > maybe tree objects returned by alloc_max_size after the change are out > of GC's tracking? > > If the suspicion holds, the attached explorative diff may help. I wouldn't expect that to make a difference. There are thousands of similar calls to build_int_cst() throughout the middle end. Looking at the original patch, the change that I'm not sure about and that shouldn't have been part of the refactoring is the call to enable_ranger() in pass_waccess::execute(). It's something I was planning to do next. But even that I wouldn't expect to eat up a whole 1GB or memory. > > BR, > Kewen > >> Previously, compiler bootstrap and all testcases ran with a data size >> of 1GB. After your change, the data size required for those >> particular testcases jumped to 2GB. >> >> The testcases are >> >> gcc/testsuite/gcc.target/powerpc/rlwimi-[012].c >> >> The failure is >> >> cc1: out of memory allocating 65536 bytes after a total of 1608979296 >> >> This seems like a significant memory use regression. Any ideas what happened? Not really. The patch just moved code around. I didn't make any changes that I'd expect to impact memory allocation to an appreciable extent, at least not intentionally. Let me look into it and get back to you. Martin >> >> Thanks, David >>