Hello,
On Wed, 9 Feb 2022, Richard Biener wrote:
> > 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 think to cause breakage you need a use of 'i' on the side-entry
> path that is not reachable from the path with the birth. I guess sth like
>
> if (nevertrue)
> goto start;
> goto forw;
> start:
> {
> int i = 0;
> printf("not really reachable, but unknowingly so\n");
> goto common;
> forw:
> i = 1;
> common:
> foo (&i);
> }
>
> if we'd have a variable that's live only on the side-entry path
> then it could share the stack slot with 'i' this way, breaking
> things (now we don't move CLOBBERs so it isn't easy to construct
> such case). The present dataflow would, for the above, indeed
> compute 'i' not live in the forw: block.
Yes, now that we have established (in the subthread with Joseph) that the
value becomes indeterminate at decls we only need to care for not sharing
storage invalidly, so yeah, some changes in the conflict computation still
are needed.
> > 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.
>
> Yes, sure. I don't see a good way to place births during gimplification
> then.
Well, for each BIND you can compute if there are side entries at all,
then, when lowering a BIND you put the births into the containing
innermost BIND that doesn't have side-entries, instead of into the current
BIND.
> The end clobbers rely on our EH lowering machinery. For the entries we
> might be able to compute GIMPLE BIND transitions during BIND lowering if
> we associate labels with BINDs. There should be a single fallthru into
> the BIND at this point. We could put a flag on the goto destination
> labels whether they are reached from an outer BIND.
>
> goto inner;
> {
> {
> int i;
> {
> int j;
> inner:
> goto middle;
> }
> middle:
> }
> }
>
> Since an entry CLOBBER is also a clobber we have to insert birth
> clobbers for all decls of all the binds inbetwee the goto source
> and the destination. So for the above case on the edge to
> inner: have births for i and j and at the edge to middle we'd
> have none.
Correct, that's basically the most precise scheme, it's what I called
try-finally topside-down ("always-before"? :) ). (You have to care for
computed goto! i.e. BINDs containing address-taken labels, which make
things even uglier) I think the easier way to deal with the above is to
notice that the inner BIND has a side entry and conceptually move the
decls outwards to BINDs that don't have such (or bind-crossing gotos),
i.e. do as if it were:
int i; // moved
int j; // moved
goto inner;
{
{
{
inner:
goto middle;
}
middle:
}
}
> Requires some kind of back-mapping from label to goto sources
> that are possibly problematic. One issue is that GIMPLE
> lowering re-builds the BLOCK tree (for whatever reason...),
> so I'm not sure if we need to do it before that (for correctness).
>
> Does that make sense?
I honestly can't say for 100% :-) It sounds like it makes sense, yes.
Ciao,
Michael.
