Hello, On Thu, 1 Jul 2021, Richard Sandiford wrote:
> Well, it does feel like this is pressing the reset button on a thread > whose message count is already in the high double figures. There's a > risk that restarting the discussion now is going to repeat a lot of the > same ground, probably at similar length. (But I realise that the sheer > length of the thread is probably also the main reason for not having > followed it closely. :-)) Yeah, I thought of not sending the mail because of that. But it itched too itchy ;-) > (2) continue to treat uses of uninitialised automatic variables as > (semantically) undefined behaviour > > When this was discussed on the clang list, (2) was a key requirement > and was instrumental in getting the feature accepted. > ... > since the behaviour is at least deterministic. But from a debugging QoI > perspective, this should not happen. We should generate the same code > as for: > > int foo = <fill-pattern>; > if (flag) > foo = 1; > x = foo; > > However, because of (2), we should still generate a > -Wmaybe-uninitialized warning for the “x = foo” assignment. > > This is not a combination we support at the moment, so something needs > to give. The question of course is what. Nothing needs to give. You add the initialization with <fill-pattern>, _without an uninitialized use_, i.e. just: foo = .deferred_init(pattern) or the like. Then you let the optimizers do their thing. If 'foo' is provably initialized (or rather overwritten in this setting) on all paths from above init to each use, that init will be removed. IOW: if the init remains then not all paths are provably initializing. I.e. the warning code can be triggered based on the simple existence of the deferred_init initializer. Basically the .deferred_init acts as a "here the scope starts" marker. That's indeed what you want, not the "here the scope ends" clobber. If a use reaches the scope-start marker you have an (possibly) uninitialized use and warn. (I'm obviously missing something because the above idea seems natural, so was probably already discussed and rejected, but why?) > > Garbage in, garbage out. It makes not too much sense to argue that > > the generated PHI node on this loop (generated because of the > > exposed-upward use of foo) is wrong, or right, or should better be > > something else. The input program was broken, so anything makes sense. > > Yeah, without the new option it's GIGO. But I think it's still possible > to rank different forms of garbage output in terms of how self-consistent > they are. > > IMO it makes no sense to say that “foo” is upwards-exposed to somewhere > where “foo” doesn't exist. Using “foo_N(D)” doesn't have that problem, > so I think it's possible to say that it's “better” garbage output. :-) > > And the point is that with the new option, this is no longer garbage > input as far as SSA is concerned: carrying the old value of “foo” > across iterations would not be implementing the option correctly. > How SSA handles this becomes a correctness issue. I disagree. The notion of "foo doesn't exist" simply doesn't exist (ugh!) in SSA; SSA is not the issue here. The notion of ranges of where foo does or doesn't exist are scopes, that's orthogonal; so you want to encode that info somehow in a way compatible with SSA (!). Doing that with explicit instructions is sensible (like marking scope endings with the clobber insn was sensible). But those instructions simply need to not work against other invariants established and required by SSA. Don't introduce new undefined uses and you're fine. > > I think it's a chicken egg problem: you can't add undefined uses, for > > which you need to know if there was one, but the facility is supposed to > > help detecting if there is one to start with. > > The idea is that .DEFERRED_INIT would naturally get optimised away by > DCE/DSE if the variable is provably initialised before it's used. Well, that's super. So, why would you want or need the uninitialized use in the argument of .DEFERRED_INIT? Ciao, Michael.
