This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minor improvement when adding call-clobbered symbols


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]