On Thu, Sep 10, 2026 at 11:56 AM Richard Sandiford
<[email protected]> wrote:
>
> Richard Biener <[email protected]> writes:
> > On Wed, Sep 9, 2026 at 3:49 PM Richard Sandiford
> > <[email protected]> wrote:
> >> I suppose the underlying problem is that recog_data shouldn't be a
> >> global variable. Copying and restoring it is a hack to get around
> >> that design decision. And that hack was borderline acceptable while
> >> the copy was simple.
> >>
> >> IMO the ideal fix would be to remove the global state and handle the
> >> cache in a different way. But that would be way too invasive. Even
> >> changing recog_data to a pointer would probably be too much churn
> >> (although I wouldn't be against it personally).
> >>
> >> So perhaps we should adopt a hack used elsewhere and make recog_data
> >> a macro that [deferences a] pointer (either global, or in crtl or
> >> something). By default the pointer points at a global recog_data_d,
> >> but backends can use an RAII class or direct pointer assignment
> >> to temporarily switch it to a temporary recog_data_d instead.
> >>
> >> It's all a bit icky, but maybe more acceptable than copying auto_vecs?
> >
> > I think this is a sound approach, not too far off existing practice in GCC.
>
> Thanks.
>
> > It sounds like this could be done separately, weeding out the save/restore
> > of recog_data_d.
> >
> > An alternative to the macro would be making it a singleton instance of
> > a class that converts to recog_data but allows the "flip" via some
> > push/pop but internally manages a stack of pointers to recog_data.
>
> It sounds like that would work for something that is accessed by pointer,
> since we could overload operator-> and operator*. But "." would always
> refer to members of the recog_data object itself, so I suppose the class
> would need to provide (say) an is_asm member that converts to bool and
> accepts bool assignments, but internally uses the top of the stack.
I originally thought of using
operator recog_data& () { return *m_recog_data; }
but I see that is not considered when seeing recog_data.<x> though.
But then you can of course stack this with a macro that does the
dereferencing.
Richard.
>
> Richard
