From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 519543983064 for ; Thu, 15 Jul 2021 13:06:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 519543983064 Received: by mail-ed1-x533.google.com with SMTP id h8so8030113eds.4 for ; Thu, 15 Jul 2021 06:06:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rwmRWQ3njFwC+Ndia70nGvCi4qAX3wZyxPFw6FV8DLM=; b=FTC3sg5GsMjV+QijgTcmpKUzRJ7v5w+XFT7PKlP6oc5aGIKQrz6gy1IwrCP80bOPHu Aq9yht7L8wuxWdjvZT6eGRmQNqDdooGSlQlqBWRMiyjW25jCKUg4uhs/q6ZKcJ5j1QaH c2BY2EEWdngY0Tt2Hvfn7YXCTv4b3DJ1TNfUqaSvUUdHNEuGW7mo5sDbKRwpvOgWf1CY JU1OdL21UXM0SJT7OKHT3iT8cVP1juklQ0oOTifL8o9s17ZWedS1Ulkjxvntpjw6CVLm WB8YUF/1slMCYnRvMl5suoK/zENjCmVsDY7RObQ8XbdQatcuZsmg6MV6jgGlkLW4reFc 39Rg== X-Gm-Message-State: AOAM530x9nRFFNciZxk60UExpHJMC+U7QJo3P24VqZzMpfsWQt1aE+pJ IIVBitkXcbnrVytiNLHkrpMhW9YSqFcLN1EpW/M= X-Google-Smtp-Source: ABdhPJzoHRDma7OB0E1rlwgdMylCIstTZD7Czp8DibXEm1P9vhaPMcYyjL+XK3H1fqiyf4WJv5wPiixsg4QewqHcOX4= X-Received: by 2002:a05:6402:3d4:: with SMTP id t20mr6951511edw.274.1626354371368; Thu, 15 Jul 2021 06:06:11 -0700 (PDT) MIME-Version: 1.0 References: <20210623150305.411460-1-aldyh@redhat.com> <21075381-4311-3e94-f48b-015373880c7c@redhat.com> <20210624134548.GS7746@tucnak> In-Reply-To: From: Richard Biener Date: Thu, 15 Jul 2021 15:06:00 +0200 Message-ID: Subject: Re: [RFC] Return NULL from gimple_call_return_type if no return available. To: Aldy Hernandez Cc: Andrew MacLeod , Jakub Jelinek , Aldy Hernandez via Gcc-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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, 15 Jul 2021 13:06:13 -0000 On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote: > > Well, if we don't adjust gimple_call_return_type() to handle built-ins > with no LHS, then we must adjust the callers. > > The attached patch fixes gimple_expr_type() per it's documentation: > > /* Return the type of the main expression computed by STMT. Return > void_type_node if the statement computes nothing. */ > > Currently gimple_expr_type is ICEing because it calls gimple_call_return_type. > > I still think gimple_call_return_type should return void_type_node > instead of ICEing, but this will also fix my problem. > > Anyone have a problem with this? It's still somewhat inconsistent, no? Because for a call without a LHS it's now either void_type_node or the type of the return value. It's probably known I dislike gimple_expr_type itself (it was introduced to make the transition to tuples easier). I wonder why you can't simply fix range_of_call to do tree lhs = gimple_call_lhs (call); if (lhs) type = TREE_TYPE (lhs); Richard. > > Aldy > > On Thu, Jun 24, 2021 at 3:57 PM Andrew MacLeod via Gcc-patches > wrote: > > > > On 6/24/21 9:45 AM, Jakub Jelinek wrote: > > > On Thu, Jun 24, 2021 at 09:31:13AM -0400, Andrew MacLeod via Gcc-patches wrote: > > >> We'll still compute values for statements that don't have a LHS.. there's > > >> nothing inherently wrong with that. The primary example is > > >> > > >> if (x_2 < y_3) > > >> > > >> we will compute [0,0] [1,1] or [0,1] for that statement, without a LHS. It > > >> primarily becomes a generic way to ask for the range of each of the operands > > >> of the statement, and process it regardless of the presence of a LHS. I > > >> don't know, maybe there is (or will be) an internal function that doesn't > > >> have a LHS but which can be folded away/rewritten if the operands are > > >> certain values. > > > There are many internal functions that aren't ECF_CONST or ECF_PURE. Some > > > of them, like IFN*STORE* I think never have an lhs, others have them, but > > > if the lhs is unused, various optimization passes can just remove those lhs > > > from the internal fn calls (if they'd be ECF_CONST or ECF_PURE, the calls > > > would be DCEd). > > > > > > I think generally, if a call doesn't have lhs, there is no point in > > > computing a value range for that missing lhs. It won't be useful for the > > > call arguments to lhs direction (nothing would care about that value) and > > > it won't be useful on the direction from the lhs to the call arguments > > > either. Say if one has > > > p_23 = __builtin_memcpy (p_75, q_23, 16); > > > then one can imply from ~[0, 0] range on p_75 that p_23 has that range too > > > (and vice versa), but if one has > > > __builtin_memcpy (p_125, q_23, 16); > > > none of that makes sense. > > > > > > So instead of punting when gimple_call_return_type returns NULL IMHO the > > > code should punt when gimple_call_lhs is NULL. > > > > > > > > > > Well, we are going to punt anyway, because the call type, whether it is > > NULL or VOIDmode is not supported by irange. It was more just a matter > > of figuring out whether us checking for internal call or the > > gimple_function_return_type call should do the check... Ultimately in > > the end it doesnt matter.. just seemed like something someone else could > > trip across if we didnt strengthen gimple_call_return_type to not ice. > > > > Andrew > >