Hello,
On Tue, 8 Feb 2022, Richard Biener wrote:
> int foo(int always_true_at_runtime)
> {
> {
> int *p;
> if (always_true_at_runtime)
> goto after;
> lab:
> return *p;
> after:
> int i = 0;
> p = &i;
> if (always_true_at_runtime)
> goto lab;
> }
> return 0;
> }
>
> For the implementation I considered starting lifetime at a DECL_EXPR
> if it exists and otherwise at the start of the BIND_EXPR. Note the
> complication is that control flow has to reach the lifetime-start
> clobber before the first access. But that might also save us here,
> since for the example above 'i' would be live via the backedge
> from goto lab.
>
> That said, the existing complication is that when the gimplifier
> visits the BIND_EXPR it has no way to know whether there will be
> a following DECL_EXPR or not (and the gimplifier notes there are
> cases a DECL_EXPR variable is not in a BIND_EXPR). My plan is to
> compute this during one of the body walks the gimplifier performs
> before gimplifying.
>
> Another complication is that at least the C frontend + gimplifier
> combination for
>
> switch (i)
> {
> case 1:
> int i;
> break;
> }
>
> will end up having the BIND_EXPR mentioning 'i' containing the
> case label, so just placing the birth at the BIND will make it
> unreachable as
>
> i = BIRTH;
> case_label_for_1:
> ...
I think anything that needs to happen (conceptually) during the jump from
switch to case-label needs to happen right before the jump, that might
mean creating a new fake BLOCK that contains just the jump and the
associated births.
> conveniently at least the C frontend has a DECL_EXPR for 'i'
> which avoids this and I did not find a way (yet) in the gimplifier
> to rectify this when gimplifying switches.
In C a 'case' label is nothing else than a normal label, it doesn't start
it's own block or the like. So also for that one the births would need to
be at the start of their containing blocks.
> So there's still work to do but I think that starting the lifetime at a
> DECL_EXPR if it exists is the way to go?
Depends on where the DECL_EXPR is exactly placed, but probably it wouldn't
be okay. You can't place the birth at the fall-through path, because this
needs to work (basically your jump example above rewritten as switch):
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.
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)
Ciao,
Michael.
