Hello,
On Tue, 8 Feb 2022, Richard Biener wrote:
> > int state = 2, *p, camefrom1 = 0;
> > for (;;) switch (state) {
> > case 1:
> > case 2: ;
> > int i;
> > if (state != 1) { p = &i; i = 0; }
> > if (state == 1) { (*p)++; return *p; }
> > state = 1;
> > continue;
> > }
> >
> > Note how i is initialized during state 2, and needs to be kept initialized
> > during state 1, so there must not be a CLOBBER (birth or other) at the
> > point of the declaration of 'i'. AFAICS in my simple tests a DECL_EXPR
> > for 'i' is placed with the statement associated with 'case 2' label,
> > putting a CLOBBER there would be the wrong thing. If the decl had an
> > initializer it might be harmless, as it would be overwritten at that
> > place, but even so, in this case there is no initializer. Hmm.
>
> You get after gimplification:
>
> state = 2;
> camefrom1 = 0;
> <D.1989>:
> switch (state) <default: <D.1996>, case 1: <D.1983>, case 2: <D.1984>>
> {
> int i;
>
> try
> {
> i = {CLOBBER(birth)}; /// ignore, should go away
> <D.1983>:
> <D.1984>:
> i = {CLOBBER(birth)};
I think this clobber here would be the problem, because ...
> which I think is OK? That is, when the abstract machine
> arrives at 'int i;' then the previous content in 'i' goes
> away? Or would
>
> int foo()
> {
> goto ick;
> use:
> int i, *p;
> return *p;
> ick:
> i = 1;
> p = &i;
> goto use;
>
> }
>
> require us to return 1?
... I think this is exactly the logical consequence of lifetime of 'i'
being the whole block. We need to return 1. (Joseph: correct me on that!
:) ) That's what I was trying to get at with my switch example as well.
> With the current patch 'i' is clobbered before the return.
>
> > Another complication arises from simple forward jumps:
> >
> > goto forw;
> > {
> > int i;
> > printf("not reachable\n");
> > forw:
> > i = 1;
> > }
> >
> > Despite the jump skiping the unreachable head of the BLOCK, 'i' needs to
> > be considered birthed at the label. (In a way the placement of births
> > exactly mirrors the placements of deaths (of course), every path from
> > outside a BLOCK to inside needs to birth-clobber all variables (in C),
> > like every path leaving needs to kill them. It's just that we have a
> > convenient construct for the latter (try-finally), but not for the former)
>
> The situation with an unreachable birth is handled conservatively
> since we consider a variable without a (visible at RTL expansion time)
> birth to conflict with all other variables.
That breaks down when a birth is there (because it was otherwise
reachable) but not on the taken path:
if (nevertrue)
goto start;
goto forw;
start:
{
int i;
printf("not really reachable, but unknowingly so\n");
forw:
i = 1;
}
> I don't see a good way to have a birth magically appear at 'forw'
> without trying to argue that the following stmt is the first mentioning
> the variable.
That's what my 'Hmm' aluded to :) The only correct and precise way I see
is to implement something similar like try-finally topside-down. An
easier but less precise way is to place the births at the (start of)
innermost block containing the decl _and all jumps into the block_. Even
less presice, but perhaps even easier is to place the births for decls in
blocks with side-entries into the function scope (and for blocks without
side entries at their start).
Except for switches side-entries are really really seldom, so we might
usefully get away with that latter solution. And for switches it might be
okay to put the births at the block containing the switch (if it itself
doesn't have side entries, and the switch block doesn't have side
entries except the case labels).
If the birth is moved to outward blocks it might be best if also the
dealloc/death clobbers are moved to it, otherwise there might be paths
containing a birth but no death.
The less precise you get with those births the more non-sharing you'll
get, but that's the price.
Ciao,
Michael.
