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.133.124]) by sourceware.org (Postfix) with ESMTPS id B67153846411 for ; Wed, 3 Apr 2024 08:35:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B67153846411 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 B67153846411 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712133329; cv=none; b=YV6i28zffYCNkKXKYpIBpILPte4TgrnDeVEVR1MM9haxPz0o4UlOvqCGJ6fi/LbUn/75kD4cvjPZe8Cu1YGWCL9PpFtF7ivJB92Nb54eXAW89i/odTFbFp1/pL3PI+hQooehnFvZzF7Pws3Qsz6K3HVWqv02VOp8nWVSMjfSias= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712133329; c=relaxed/simple; bh=ngt0pz/quZFncJS33Wqc+4G98DZs7pqYG4HrJWE1nLQ=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=jheHRNYyXbqxcsFTGyIujJ6qBsCtW4ZuDXWol2csJ5Jui1FTAC79fbLAwnKcht4i55VPT5cONK4u5P9B7OFUolwp3Xl12+zdLQGsM2O163hUIHf+TV7QJvorjlUnevajEyBgTNaaE8jLvG+rAuTkgZpgQQ/aPi3EAzTPBBNsWCc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712133327; 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=Qb3XAEWO4gPiDgd6yrwE9KtKjCBoCCQklZSrOd/VF0M=; b=goIY1huXOTiwKb9QjuSEoIkUN8ARWPJFo2K58hxHxibiNzqrQ0m7e3NMsMPxIAB5OPCpf8 VkkezvCVBwISwdNp8YZW586Ak+Da3kGRTorbgQCmODLg/iQrBnrRsJV3nS9gCVkzB+qLeW hlWN1/AQM+wC2l1h9XSLEOCRub8U6wg= 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-648-Pj5jZtplM7uniQq_NUmLwg-1; Wed, 03 Apr 2024 04:35:22 -0400 X-MC-Unique: Pj5jZtplM7uniQq_NUmLwg-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 C7F173803901; Wed, 3 Apr 2024 08:35:20 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 75AB7492BCD; Wed, 3 Apr 2024 08:35:20 +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 4338ZE3L1845352 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 3 Apr 2024 10:35:14 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4338ZDvw1845351; Wed, 3 Apr 2024 10:35:13 +0200 Date: Wed, 3 Apr 2024 10:35:12 +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> MIME-Version: 1.0 In-Reply-To: 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 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 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. > since from the > perspective of resulted assembly, with this workaround, the callee can: > 1) pass the hidden args in unexpected GPR like r11, ... at -O0; > 2) get rid of such hidden args as they are unused at -O2; > This proposal aims to make the assembly at -O0 not to pass with r11... (same as -O2), > comparing to the assembly at O2, the mismatch isn't actually changed. The aim for the workaround was just avoid assuming there is a argument save area in the caller stack when it is sometimes missing. If you are looking for optimizations where nothing actually passes the unneeded arguments and nothing expects them to be passed, then it is a task for IPA optimizations and should be done solely if IPA determines that all callers can be adjusted together with the callee; I think IPA already does that in that case for years, regardless if it is DECL_HIDDEN_STRING_LENGTH PARM_DECL or not. Jakub