> O.K., if 'a' is declared static, then it is immune from tampering by a
> shared library. However, I was hoping that IPA would be able to tell
> that neither glarp() nor any of its callees reference variable 'a'. If a
> shared library was going to reference 'a', then glarp() or one of its
> callees would be invoking an external function somewhere; they don't,
> and IPA should know that.
And I think IPA does know that. I still conjecture that the problem is
that the optimizer has no way (with the present infrastructure) to
represent the info it gets from IPA in full detail. When there is no
inlining, the glarp() call *MUST* be marked as possibly modifying the
return vsym (because glarp() calls bling() which changes b, which is
state that persists across the return from main() and is visible
outside main()).
Furthermore, since a is also a part of persistent state visible after
main() returns, a will alias with the return vsym(). Since the
optimizer represents the virtual variables this way, it cannot assume
that the glarp() call does not use the value of a. This, I believe, is
why the "a = 2" assignment doesn't get deleted when no inlining
occurs.
With inlining, there are no calls and the optimizer can see
everything. In that case it does the right thing.
> Is there anything I can do to allow IPA to delete this store? (Other
> than enabling the inliner :-)
IPA will never delete the store. The optimizer will delete it if
anyone does. If my conjecture is right, you need to make "a" something
that won't alias with the return vsym; in other words, you need to
make "a" some sort of variable that the optimizer knows will not be
used or modified after main()'s return.
-- Robert
|