From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9FE783847700 for ; Wed, 3 Apr 2024 09:23:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FE783847700 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9FE783847700 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712136227; cv=none; b=dDLejJ606wJg3yPhFMX1VFceFVLkZatZoqtdJyZBZcrAc4fVg/apGkngiSZmXKcmmQgkrJwmafe+qmdE8uFmGVOXBBuQsjOT9hdzmgr2AmCFaBdWmygKWkAAX7/RxU9j/Q2JYEsbLc8GLoM4JJVKxsHihlbYVakLofUGoXLaW+w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712136227; c=relaxed/simple; bh=u9QJHBN9mq9NInNMMpMlwp8yF16kb3TDaNQ+D75AGAo=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ByL94mM+QAWWkTdmWDyHFe5oYp6323s48eX5i8bG1jEXK8+mn9MIjNUPIeYBXVccdSLR//7LU+rCi0ZpviwAxHOqU2Ug/OOkxa0kxC7H74FPItjLcGxLaY2BU7bGbqWrV7QKjR27q9pamsnbRB3XtuuddUjkG/L/xaGs10GNoR4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712136225; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=l8By+OF9LR6bKPNyqfF2ASzLTLahGeLO2FdW5CWQ7d0=; b=OUjl5/GEkyrTIDHbkXieGHHjAu60EClbOUIcmsr3Inw6We2kEWcl64qZtrOAvPvCuOnQ9U G4uTBgKY8E53lbzeLjgT/1/Ded7OSFeGq+8m2Tq8/yuT6HD8dWkSVtSl/4M83jc5gMqlEP Pj+gNM2f+Xi2v+EcV+VOPIu0tK8KDps= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-147-lskcGBsrOCmsMRZd1M39kw-1; Wed, 03 Apr 2024 05:23:41 -0400 X-MC-Unique: lskcGBsrOCmsMRZd1M39kw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 432EF383CCE5; Wed, 3 Apr 2024 09:23:41 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0726D492BCD; Wed, 3 Apr 2024 09:23:40 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4339NZ0R1845495 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 3 Apr 2024 11:23:35 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4339NYuG1845494; Wed, 3 Apr 2024 11:23:34 +0200 Date: Wed, 3 Apr 2024 11:23:34 +0200 From: Jakub Jelinek To: "Kewen.Lin" Cc: Ajit Agarwal , Peter Bergner , Segher Boessenkool , David Edelsohn , Michael Meissner , gcc-patches Subject: Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799] Message-ID: Reply-To: Jakub Jelinek References: <8e8dad73-43a6-4764-a496-b600e6a220e1@linux.ibm.com> <76307976-77b0-48f0-90b9-6dcec02e3c8f@linux.ibm.com> <6a592b9f-d536-4a0e-aa00-ee8d4a778afc@linux.ibm.com> <5a2e511a-3a29-4cdd-88b1-12a6274d5a79@linux.ibm.com> <5293fc93-5899-8863-e776-e2a75b0d97a4@linux.ibm.com> MIME-Version: 1.0 In-Reply-To: <5293fc93-5899-8863-e776-e2a75b0d97a4@linux.ibm.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote: > on 2024/4/3 16:35, Jakub Jelinek wrote: > > On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote: > >>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments that just some > >>> invalid code doesn't pass. By removing them you basically always create an > >>> invalid case, this time in the other direction, valid caller passes more > >>> arguments than the callee (invalidly) expects. > >> > >> Thanks for the comments, do you mean it can affect the arguments validation when there > >> is explicit function declaration with interface? Then can we strip them when we are > >> going to expand them (like checking currently_expanding_function_start)? > > > > I'd prefer not stripping them at all; they are clearly marked as perhaps not > > passed in buggy programs (the DECL_HIDDEN_STRING_LENGTH argument) and > > removing them implies the decl is a throw away, that after expansion > > Yes, IMHO it's safe as they are unused. But they are still passed in the usual case. > > nothing will actually look at it anymore. I believe that is the case of > > function bodies, we expand them into RTL and throw away the GIMPLE, and > > after final clear the bodies, but it is not the case of the FUNCTION_DECL > > or its DECL_ARGUMENTs etc. E.g. GIMPLE optimizations or expansion of > > callers could be looking at those as well. > > At expand time GIMPLE optimizations should already finish, so it should be > safe to strip them at that time? No. The IPA/post IPA behavior is that IPA optimizations are performed and then cgraph finalizes one function at a time, going there from modifications needed from IPA passes, post IPA GIMPLE optimizations, expansion to RTL, RTL optimizations, emitting assembly, throwing away the body, then picking another function and repeating that etc. So, when one function makes it to expansion, if you modify its DECL_ARGUMENTS etc., all the post IPA GIMPLE optimization passes of other functions might still see such changes. > It would surprise me if expansions of > callers will look at callee's information, it's more like what should be > done in IPA analysis instead? Depends on what exactly it is. E.g. C non-prototyped functions have just DECL_ARGUMENTS to check how many arguments the call should have vs. what is actually passed. > No, it's not what I was looking for. Peter's comments made me feel it's not > good to have assembly at O0 like: > > std %r3,112(%r31) > std %r4,120(%r31) > std %r5,128(%r31) > std %r6,136(%r31) > std %r7,144(%r31) > std %r8,152(%r31) > std %r9,160(%r31) > std %r10,168(%r31) > std %r11,176(%r31) // this mislead people that we pass 9th arg via r11, > // it would be nice not to have it. > > so I was thinking if there is some way to get rid of it. You want to optimize at -O0? Don't. That will screw up debugging. The function does have that argument, it should show up in debug info; it should show up also at -O2 in debug info etc. If you remove chains from DECL_ARGUMENTS, because we have early dwarf these days, DW_TAG_formal_parameter nodes should have been already created, but it would mean that DW_AT_location for those arguments likely isn't filled. Now, for -O2 it might be the case that the argument has useful location only at the start of the function, could have DW_OP_entry_value(%r11) afterwards, but at -O0 it better should have some stack slot into which the argument is saved and DW_AT_location should be that stack slot. All that should change with the workaround is that if the stack slot would be normally in the argument save area in the caller's frame, if such argument save area can't be counted on, then it needs to be saved in some other stack slot, like arguments are saved to when there are only <= 8 arguments. Now, sure, if IPA optimizes a call because it can prove it sees a callee and all its callers and can modify them all, it can optimize away passing of that argument but 1) it isn't done at -O0/-Og 2) it ensures debug info reflects the case that the argument isn't passed and arranges for the callers to provide DW_OP_GNU_parameter_ref/call site info value 3) it doesn't modify the FUNCTION_DECL itself or its DECL_ARGUMENTS, but makes a clone of the FUNCTION_DECL and modifies the clones DECL_ARGUMENTS Jakub