Minor improvement when adding call-clobbered symbols

Daniel Berlin dberlin@dberlin.org
Mon Mar 5 17:22:00 GMT 2007


On 3/5/07, Diego Novillo <dnovillo@redhat.com> wrote:
> Daniel Berlin wrote on 03/04/07 18:24:
> > On 3/2/07, Diego Novillo <dnovillo@redhat.com> wrote:
> >> If a memory tag T is call-clobbered, the operand scanner will blindly
> >> add *all* the members of T's alias set to every call-site, regardless of
> >> their individual clobbered state.
> >
> > I assume the only case this really matters is when we partition,
>
> No, it's unrelated.  See the test case included in the patch.
> The name tag is call-clobbered but not all the members in its may-alias
> set are marked call-clobbered.  This happens when the tag is marked
> call-clobbered not because its parent pointer escapes, but because one
> of the member of its alias set are call-clobbered (this is a fairly
> long-lived wart we have in our analysis that would be nice to remove).
>
> > because compute_call_clobbered should mark all aliases of a clobbered
> > tag as themselves clobbered, unless they are unmodifiable_var_p.
> >
> > (see compute_call_clobbered and mark_aliases_call_clobbered)
>
> No, the tag is getting marked call-clobbered *after* we've done the
> transitive closure.  The pointer does not escape, so we had no reason to
> mark the tag as call-clobbered.  However, one or more members in the
> alias set have their addresses escaping from the function, so we decided
> to mark the tag call-clobbered in compute_tag_properties.
>
> The patch is triggering some other bug in this area (PRs 31036 and
> 31037).  I'm almost tempted now to stop compute_tag_properties from
> marking parent-tags as call-clobbered, but I remember other oddities if
> we didn't do this.  I'll take a look.

If you don't do this, it will never add the call clobbered symbol
(because of how the operand scanner works), IIRC.
At least, this is what i remember.

>
> If this approach works, then we can skip non-call-clobbered vars in the
> operand scanner and assert that they are unmodifiable_var_p.
>
>



More information about the Gcc-patches mailing list