This is the mail archive of the
mailing list for the GCC project.
Re: Minor improvement when adding call-clobbered symbols
On 3/5/07, Diego Novillo <firstname.lastname@example.org> wrote:
Daniel Berlin wrote on 03/04/07 18:24:
> On 3/2/07, Diego Novillo <email@example.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.