On Tue, May 25, 2021 at 11:36 AM Aldy Hernandez <al...@redhat.com> wrote: > > > > On 5/25/21 10:57 AM, Richard Biener wrote: > > On Mon, May 24, 2021 at 6:44 PM Aldy Hernandez via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > >> > >> > >> > >> On 5/21/21 1:39 PM, Aldy Hernandez wrote: > >>> This patch provides a generic API for accessing global ranges. It is > >>> meant to replace get_range_info() and get_ptr_nonnull() with one > >>> common interface. It uses the same API as the ranger (class > >>> range_query), so there will now be one API for accessing local and > >>> global ranges alike. > >>> > >>> Follow-up patches will convert all users of get_range_info and > >>> get_ptr_nonnull to this API. > >>> > >>> For get_range_info, instead of: > >>> > >>> if (!POINTER_TYPE_P (TREE_TYPE (name)) && SSA_NAME_RANGE_INFO (name)) > >>> get_range_info (name, vr); > >>> > >>> You can now do: > >>> > >>> RANGE_QUERY (cfun)->range_of_expr (vr, name, [stmt]); > >> > >> BTW, we're not wed to the idea of putting the current range object in > >> cfun. The important thing is that the API is consistent across, not > >> where it lives. > > > > If the range object is specific for a function (and thus cannot handle > > multiple functions in IPA mode) then struct function looks like the correct > > place. Accessing that unconditionally via 'cfun' sounds bad though because > > that disallows use from IPA passes. > > The default range object can either be the "global_ranges" object > (get_range_info / get_ptr_nonnull wrapper) or a ranger. So, the former > is global in nature and not tied to any function, and the latter is tied > to the gimple IL in a function. > > What we want is a mechanism from which a pass can query the range of an > SSA (or expression) at a statement or edge, etc agnostically. If a > ranger is activated, use that, otherwise use the global information. > > For convenience we wanted a mechanism in which we didn't have to pass an > object between functions in a pass (be it a ranger or a struct > function). Back when I tried to convert some passes to a ranger, it was > a pain to pass a ranger object around, and having to pass struct > function would be similarly painful. > > ISTM, that most converted passes in this patchset already use cfun > throughout. For that matter, even the two IPA ones (ipa-fnsummary and > ipa-prop) use cfun throughout (by first calling push_cfun (node->decl)). > > How about I use fun if easily accessible in a pass, otherwise cfun? I'm > trying to avoid having to pass around a struct function in passes that > require surgery to do so (especially when they're already using cfun). > > Basically, we want minimal changes to clients for ease of use.
I think it's fine to not fix "endusers", esp. if they already use 'cfun' and fixing would be a lot mechanical work. What we need to avoid is implicit uses of cfun via APIs we introduce because that makes a pass/API that is "cfun" clean, eventually even working on explicit struct function (and thus IPA safe) no longer so and depend on "cfun" without that being visible. The GSoC project to do threading did some cleanups here and there and in the past we've transitioned to explicit 'cfun' uses like BASIC_BLOCK_FOR_FN, etc. to expose those and make pass refactorings meaningful so that a pass using passed around 'cfun' would survive with setting cfun to NULL. Richard. > Aldy >
