On 7/10/22 12:19, Roger Sayle wrote: > This patch builds upon Richard Biener's suggestion of avoiding global > variables to track state/identify which passes have already been run. > In the early middle-end, the tree-ssa passes use the curr_properties > field in cfun to track this. This patch uses a new rtl_pass_progress > int field in crtl to do something similar. > > This patch allows the global variables lra_in_progress, reload_in_progress, > reload_completed, epilogue_completed and regstack_completed to be removed > from rtl.h and implemented as bits within the new crtl->rtl_pass_progress. > I've also taken the liberty of adding a new combine_completed bit at the > same time [to respond the Segher's comment it's easy to change this to > combine1_completed and combine2_completed if we ever perform multiple > combine passes (or multiple reload/regstack passes)]. At the same time, > I've also refactored bb_reorder_complete into the same new field; > interestingly bb_reorder_complete was already a bool in crtl. > > One very minor advantage of this implementation/refactoring is that the > predicate "can_create_pseudo_p ()" which is semantically defined to be > !reload_in_progress && !reload_completed, can now be performed very > efficiently as effectively the test (progress & 12) == 0, i.e. a single > test instruction on x86. > > For consistency, I've also moved cse_not_expected (the last remaining > global variable in rtl.h) into crtl, as its own bool field. > > The vast majority of this patch is then churn to handle these changes. > Thanks to macros, most code is unaffected, assuming it treats those > global variables as r-values, though some source files required/may > require tweaks as these "variables" are now defined in emit-rtl.h > instead of rtl.h. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32}, > with no new failures. Might this clean-up be acceptable in stage 1, > given the possible temporary disruption transitioning some backends? > I'll start checking various backends myself with cross-compilers, but if > Jeff Law could spin this patch on his build farm, that would help > identify targets that need attention. Do you have any intention on moving forward with this?    I like what you've done and I've been carrying around changes to make it work across a much wider set of targets.   Many targets want to treat reload_in_progress and reload_completed as lvalues in their thunk code, so they need simple adjustments. I suspect some of the untested targets like ia64 will need obvious adjustments.  The patch I've had in my tester for the last few months is attached... Jeff