This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Eliminate write-only variables
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>,GCC Patches <gcc-patches at gcc dot gnu dot org>,Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 02 Jun 2014 20:54:46 +0200
- Subject: Re: Eliminate write-only variables
- Authentication-results: sourceware.org; auth=none
- References: <20140516172559 dot GF20755 at kam dot mff dot cuni dot cz> <53791418 dot 3060501 at codesourcery dot com> <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>
On June 2, 2014 5:44:13 PM CEST, Jan Hubicka <hubicka@ucw.cz> wrote:
>>
>> Well, I'm hesitant to add a new pass just to optimize a (irrelevant
>in practice)
>> benchmark. I'm ok with strengthening existing infrastructure or
>enhancing
>> existing passes.
>>
>> The issue with these mini-passes is that they are very placement
>sensitive
>> and you don't easily get secondary effects. See the comment (and
>> "patch") about DCE - the ??? comment can be addressed the same
>> way Bernd addressed it (use cgraph_function_possibly_inlined_p).
>> Would that optimize the testcase?
>>
>> Note that the issue with nested function use prevails (not sure how
>to
>> solve that - same issue in Bernds patch).
>
>I think this part of the patch can be made much cleaner by simply
>adding flag
>"used by one function only" to variables. We can compute it at the end
>of IPA
>queue and remove the code playing with local statics, nested functions
>and inlines.
>
>I can easily implement this analysis - perhaps it would be useful for
>AA or
>something else, too?
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 and deck_may_have_address_taken.
Richard.
>Honza
>>
>> Thanks,
>> Richard.
>>
>> > -Sandra
>> >