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. Richard
