Re: [PATCH] strub: use opt_for_fn during ipa

[Alexandre Oliva <oliva@adacore.com>]

On Dec 15, 2023, Richard Biener <rguenther@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.

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

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive