On Tue, 19 Dec 2023, Alexandre Oliva wrote: > On Dec 15, 2023, Richard Biener <rguent...@suse.de> wrote: > > > You have to be generally careful when working within IPA > > with function bodies without push/pop_cfun around that, several APIs > > have variants with struct function sepcified, using the wrong one > > will get you a NULL cfun which _some_ of them handle gracefully and > > "wrong", all EH stuff is amongst this for example. > > *nod*, I recall running into that, and finding some APIs that required > push/pop_cfun, so since I was implementing strub so that it could be > plugged into an existing compiler, I didn't give much thought to > introducing alternate APIs that could. IIRC I first hit something about > EH, and then I had to put in push/pop_cfun. That was very early on, so > after that I may have used implicit-cfun APIs without getting ICEs. I > suppose now that strub is in pursuing push/pop_cfun avoidance could be a > nice cleanup.
Yeah, adding API variants with explicit struct function is considered OK when that allows to avoid push/pop_cfun. When playing with stmts the first thing you'll hit is update_stmt (though it's core worker, update_stmt_operands has the arg already). Sometimes the cfun dependence isn't really obvious ... > > I see you replace flag_exceptions with opt_for_fn (cfun->decl, > > flag_exceptions), given that's 'cfun' this replacement is a no-op > > given 'cfun' would be NULL in IPA context unless you pushed a function. > > > Looking at the 2nd hunk and the caller it seems the transform is > > a no-op for indrect_calls but not callees, thus that hunk is OK. > > Yeah, I figured that was the reason behind your recommendation, but I > guess adding explicit uses of cfun (rather than passing a function > around) doesn't really make things much better, except inasmuchas it > enables a future de-cfun-ification of strub passes to be a little more > mechanical. Yep, we've gone through some of GCCs APIs where there was two variants, one with and one without explicit struct function arg and eliminating the first in favor of explicit mentioning of 'cfun' to show where we depend on that. That was in the context of eventually threading parts of GCC which of course doesn't play well with this kind of global state. Richard.
