This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Eliminate write-only variables
- From: Martin Jambor <mjambor at suse dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 3 Jun 2014 11:17:15 +0200
- Subject: Re: Eliminate write-only variables
- Authentication-results: sourceware.org; auth=none
- References: <20140518205956 dot GG1828 at kam dot mff dot cuni dot cz> <53797044 dot 2050704 at codesourcery dot com> <537AD329 dot 7070502 at codesourcery dot com> <20140520042958 dot GD8734 at kam dot mff dot cuni dot cz> <CAFiYyc1R+AX6PYM2edpuQ9fpw89TFLZ3=wiXXaDT31CRZJaYxA at mail dot gmail dot com> <538A1D9B dot 4010901 at codesourcery dot com> <CAFiYyc0V+Qt35eq3fd_RxXgTdS1uYpE4oia2qcOW4f66REzEBA at mail dot gmail dot com> <20140602154413 dot GA16816 at kam dot mff dot cuni dot cz> <fef41708-6392-4dba-b2bd-17326fc565b3 at email dot android dot com> <20140602185935 dot GA14773 at kam dot mff dot cuni dot cz>
On Mon, Jun 02, 2014 at 08:59:35PM +0200, Jan Hubicka wrote:
> >
> > Yeah, I discussed this with martin today on irc. For aliasing we'd like to know whether a decl possibly has its address taken. Currently we only trust TREE_ADDRESSABLE for statics - and lto might change those to hidden visibility public :(
> >
> > So we want deck_referred_to_by_single_function
>
> OK, I will implement this one in IPA mini-pass. It is easy.
> This property changes by clonning and inlining. What Martin wants to use it for?
> (I.e. my plan would be to compute it as last IPA pass making it useless for
> IPA analysis&propagation)
That is a misunderstanding, I don't plan to use it for anything. It
was just a part of a discussion about this thread where I simply
proposed exactly the same thing as you did now.
Martin
>
> > and deck_may_have_address_taken.
>
> We currently clear TREE_ADDRESSABLE for statics that have no address taken at
> WPA time and that ought to keep the flag cleared at ltrans (I think I even made
> testcase for this)
>
> What I think we could improve is to not consider string functions as ADDR operations
> for this analysis, i.e. it is common to only memset to 0.
>
> How may_have_address_taken would differ here?
>
> Honza