Message ID | 20220113091052.GS2646553@tucnak |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8139B3890437 for <patchwork@sourceware.org>; Thu, 13 Jan 2022 09:11:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8139B3890437 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1642065091; bh=+p7BlW8/diiSIW9y35H2yh8KVwWf5KlLr8GpUwdWA7o=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=lL9bkOtu0gqyVIerK/Ja14DlrEvzFoJLyipGQPIjyvutObu2TCpdfXgc0W+ajcRps yVd0XUgoSJ8zSE2IkRxiGPLVgYDzobhsZZa5jASoKaj6LqYWWmL08gKJZtkgXCz9EN Yj/5ZxiHRZyGABQ5Cy6+A0wW0CED8S4Ijzc+5hB8= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 C9A213858D39 for <gcc-patches@gcc.gnu.org>; Thu, 13 Jan 2022 09:11:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9A213858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-629-EmaCQH0cNxKEz5Zu4Xsm3g-1; Thu, 13 Jan 2022 04:11:01 -0500 X-MC-Unique: EmaCQH0cNxKEz5Zu4Xsm3g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4745D5229; Thu, 13 Jan 2022 09:10:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.246]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A7B2510E81FB; Thu, 13 Jan 2022 09:10:56 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 20D9ArXS2504161 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 13 Jan 2022 10:10:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20D9AqTs2504160; Thu, 13 Jan 2022 10:10:52 +0100 Date: Thu, 13 Jan 2022 10:10:52 +0100 To: Richard Biener <rguenther@suse.de>, Jason Merrill <jason@redhat.com> Subject: [PATCH] inliner: Don't emit copy stmts for empty type parameters [PR103989] Message-ID: <20220113091052.GS2646553@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jakub Jelinek <jakub@redhat.com> Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
inliner: Don't emit copy stmts for empty type parameters [PR103989]
|
|
Commit Message
Jakub Jelinek
Jan. 13, 2022, 9:10 a.m. UTC
Hi! The following patch avoids emitting a parameter copy statement when inlining if the parameter has empty type. E.g. the gimplifier does something similar (except that it needs to evaluate side-effects if any, which isn't the case here): /* For empty types only gimplify the left hand side and right hand side as statements and throw away the assignment. Do this after gimplify_modify_expr_rhs so we handle TARGET_EXPRs of addressable types properly. */ if (is_empty_type (TREE_TYPE (*from_p)) && !want_value /* Don't do this for calls that return addressable types, expand_call relies on those having a lhs. */ && !(TREE_ADDRESSABLE (TREE_TYPE (*from_p)) && TREE_CODE (*from_p) == CALL_EXPR)) { gimplify_stmt (from_p, pre_p); gimplify_stmt (to_p, pre_p); *expr_p = NULL_TREE; return GS_ALL_DONE; } Unfortunately, this patch doesn't cure the uninit warnings in that PR, but I think is desirable anyway. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-01-13 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/103989 * tree-inline.c (setup_one_parameter): Don't copy parms with empty type. Jakub
Comments
On Thu, 13 Jan 2022, Jakub Jelinek wrote: > Hi! > > The following patch avoids emitting a parameter copy statement when inlining > if the parameter has empty type. E.g. the gimplifier does something similar > (except that it needs to evaluate side-effects if any, which isn't the case > here): > /* For empty types only gimplify the left hand side and right hand > side as statements and throw away the assignment. Do this after > gimplify_modify_expr_rhs so we handle TARGET_EXPRs of addressable > types properly. */ > if (is_empty_type (TREE_TYPE (*from_p)) > && !want_value > /* Don't do this for calls that return addressable types, expand_call > relies on those having a lhs. */ > && !(TREE_ADDRESSABLE (TREE_TYPE (*from_p)) > && TREE_CODE (*from_p) == CALL_EXPR)) > { > gimplify_stmt (from_p, pre_p); > gimplify_stmt (to_p, pre_p); > *expr_p = NULL_TREE; > return GS_ALL_DONE; > } > Unfortunately, this patch doesn't cure the uninit warnings in that PR, > but I think is desirable anyway. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Hmm, but not emitting the initialization might cause even more such warnings for the case where the passed in argument _is_ initialized (or not visible as not, like when being a function parameter itself)? Otherwise sure, it's the same what the gimplifier does. I wonder if instead uninit warning should simply ignore uses of "empty" typed variables? OK. Thanks, Richard. > 2022-01-13 Jakub Jelinek <jakub@redhat.com> > > PR tree-optimization/103989 > * tree-inline.c (setup_one_parameter): Don't copy parms with > empty type. > > --- gcc/tree-inline.c.jj 2022-01-11 23:11:23.422275652 +0100 > +++ gcc/tree-inline.c 2022-01-12 18:37:44.119950128 +0100 > @@ -3608,7 +3608,7 @@ setup_one_parameter (copy_body_data *id, > init_stmt = gimple_build_assign (def, rhs); > } > } > - else > + else if (!is_empty_type (TREE_TYPE (var))) > init_stmt = gimple_build_assign (var, rhs); > > if (bb && init_stmt) > > Jakub > >
On Thu, Jan 13, 2022 at 10:54:15AM +0100, Richard Biener wrote: > > The following patch avoids emitting a parameter copy statement when inlining > > if the parameter has empty type. E.g. the gimplifier does something similar > > (except that it needs to evaluate side-effects if any, which isn't the case > > here): > > /* For empty types only gimplify the left hand side and right hand > > side as statements and throw away the assignment. Do this after > > gimplify_modify_expr_rhs so we handle TARGET_EXPRs of addressable > > types properly. */ > > if (is_empty_type (TREE_TYPE (*from_p)) > > && !want_value > > /* Don't do this for calls that return addressable types, expand_call > > relies on those having a lhs. */ > > && !(TREE_ADDRESSABLE (TREE_TYPE (*from_p)) > > && TREE_CODE (*from_p) == CALL_EXPR)) > > { > > gimplify_stmt (from_p, pre_p); > > gimplify_stmt (to_p, pre_p); > > *expr_p = NULL_TREE; > > return GS_ALL_DONE; > > } > > Unfortunately, this patch doesn't cure the uninit warnings in that PR, > > but I think is desirable anyway. > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > Hmm, but not emitting the initialization might cause even more such > warnings for the case where the passed in argument _is_ initialized > (or not visible as not, like when being a function parameter itself)? Most of the time it won't be initialized either, but sure, there can be some cases like when a larger struct is initialized with memset and then we pass a field from that as an argument. > Otherwise sure, it's the same what the gimplifier does. > > I wonder if instead uninit warning should simply ignore uses of > "empty" typed variables? Apparently it does already: /* Avoid warning about empty types such as structs with no members. The first_field() test is important for C++ where the predicate alone isn't always sufficient. */ tree rhstype = TREE_TYPE (rhs); if (POINTER_TYPE_P (rhstype)) rhstype = TREE_TYPE (rhstype); if (is_empty_type (rhstype)) return NULL_TREE; Though, the above if (POINTER_TYPE_P (rhstype)) rhstype = TREE_TYPE (rhstype); is just extremely suspicious, either we care about what type rhs has, or it is dereferenced and it must be a pointer type and we care about what it points to, but the simple fact whether rhs has a pointer type or some other type shouldn't change what we test is_empty_type on. When I was briefly looking at the assignment on which it actually warned, it actually looked not empty type related. Jakub
--- gcc/tree-inline.c.jj 2022-01-11 23:11:23.422275652 +0100 +++ gcc/tree-inline.c 2022-01-12 18:37:44.119950128 +0100 @@ -3608,7 +3608,7 @@ setup_one_parameter (copy_body_data *id, init_stmt = gimple_build_assign (def, rhs); } } - else + else if (!is_empty_type (TREE_TYPE (var))) init_stmt = gimple_build_assign (var, rhs); if (bb && init_stmt)