Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Mon, Jun 24, 2019 at 04:28:34PM +0200, Jakub Jelinek wrote: >> On Sun, Jun 23, 2019 at 02:51:06PM +0100, Richard Sandiford wrote: >> > What do you think? Is it worth pursuing this further? >> >> Wouldn't it be more useful to just force all automatic variables to be >> used at the end of their corresponding scope?
This is what patch 2 does FWIW. >> That is IMHO the main issue >> with -Og debugging, VTA is a best effort, if we can express a variable with >> some expression, nice, but if there is no expression nor memory nor register >> that holds the value, we are out of luck. Could be some magic stmt like >> gimple_clobber or ifn or something similar, which would make sure that at >> least until expansion to RTL we force those vars to be live in either a >> register or memory. >> I'm afraid having different modes, one in which debug stmts can't and one >> where they can affect code generation might be a maintainance nightmare. Very few places need to check for the mode explicitly. Most code just uses a new test instead of (rather than on top of) is_gimple_debug/ NONDEBUG_INSN_P. The vast majority of the existing tests for is_gimple_debug aren't interested in the debug contents of a debug stmt. They're just interested in whether the stmt is allowed to affect codegen. With this series that becomes a new predicate in its own right. We then only use is_gimple_debug if we want to process the contents of a debug insn in a particular way, just like we only test for gimple calls or assignments when we're interested in their contents. Old habits die hard of course, so there'd definitely be a period while people instinctively use is_gimple_debug/NONDEBUG_INSN_P instead of the new test. > This is pretty much exactly what USE in RTL is? Maybe use a similar name > in Gimple? Yeah, I wondered about doing it that way, but one problem with USE is that it isn't clear why the USE is there or what the ordering constraints on it are. Here we want the same rules as for normal debug stmts (as modified by patch 1). Also, if the final value ends up being constant, it's fine to propagate that value into the debug stmt that marks the end of the scope. I'm not sure it's valid to propagate constants into a use. But the rtl side of patch 2 (using debug insns instead of USEs) is only a small change. The main part of it is on the gimple side. Unless we prevent all user values from becoming gimple registers and being rewritten into SSA, we'd still need something like the gimple side of patch 2 to ensure that there's sufficient tracking of the variable. Thanks, Richard
