On Tue, Jun 3, 2014 at 6:19 PM, Jan Hubicka wrote:
>> On Mon, Jun 2, 2014 at 8:59 PM, 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_ADDRESSAB
> On Mon, Jun 2, 2014 at 8:59 PM, 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
>
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
On Mon, Jun 2, 2014 at 8:59 PM, 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
>> visibilit
>
> 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_f
On June 2, 2014 5:44:13 PM CEST, Jan Hubicka 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 v
>
> 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 seconda
On Sat, May 31, 2014 at 8:21 PM, Sandra Loosemore
wrote:
> On 05/20/2014 04:56 AM, Richard Biener wrote:
>>
>> On Tue, May 20, 2014 at 6:29 AM, Jan Hubicka wrote:
On 05/18/2014 08:45 PM, Sandra Loosemore wrote:
>
> On 05/18/2014 02:59 PM, Jan Hubicka wrote:
>>
>> For cas
On 05/20/2014 04:56 AM, Richard Biener wrote:
On Tue, May 20, 2014 at 6:29 AM, Jan Hubicka wrote:
On 05/18/2014 08:45 PM, Sandra Loosemore wrote:
On 05/18/2014 02:59 PM, Jan Hubicka wrote:
For cases like local-statics-7 your approach can be "saved" by adding
simple IPA analysis
to look for st
Hi,
On Wed, May 21, 2014 at 05:10:55AM +0200, Jan Hubicka wrote:
> >
> > Unfortunately, this commit has caused the following ICE for me when
> > LTO building 471.omnetpp from SPEC 2006 or Firefox (but not libxul,
> > something that gets built earlier):
> >
> > lto1: internal compiler error: in g
>
> Unfortunately, this commit has caused the following ICE for me when
> LTO building 471.omnetpp from SPEC 2006 or Firefox (but not libxul,
> something that gets built earlier):
>
> lto1: internal compiler error: in gimple_get_virt_method_for_vtable,
> at gimple-fold.c:3276
> 0x7437a3 gimple_ge
Hi,
On Fri, May 16, 2014 at 07:25:59PM +0200, Jan Hubicka wrote:
> Hi,
> this patch adds code to remove write only static variables. While analyzing
> effectivity of LTO on firefox, I noticed that surprisingly large part of
> binary's data segment is occupied by these. Fixed thus.
> (this is qui
On Tue, May 20, 2014 at 6:29 AM, Jan Hubicka wrote:
>> On 05/18/2014 08:45 PM, Sandra Loosemore wrote:
>> >On 05/18/2014 02:59 PM, Jan Hubicka wrote:
>> >>For cases like local-statics-7 your approach can be "saved" by adding
>> >>simple IPA analysis
>> >>to look for static vars that are used only
> On 05/18/2014 08:45 PM, Sandra Loosemore wrote:
> >On 05/18/2014 02:59 PM, Jan Hubicka wrote:
> >>For cases like local-statics-7 your approach can be "saved" by adding
> >>simple IPA analysis
> >>to look for static vars that are used only by one function and keeping
> >>your DSE code active
> >>f
On 05/18/2014 08:45 PM, Sandra Loosemore wrote:
On 05/18/2014 02:59 PM, Jan Hubicka wrote:
For cases like local-statics-7 your approach can be "saved" by adding
simple IPA analysis
to look for static vars that are used only by one function and keeping
your DSE code active
for them, so we can sti
On Sun, 18 May 2014, Sandra Loosemore wrote:
> H, I'm guessing this was some concern about invalid code motion around a
> setjmp. Our original analysis document lists "F does not call setjmp" as a
> requirement for the optimization, so this was probably a case where we were
> being excessivel
On Sun, May 18, 2014 at 10:59 PM, Jan Hubicka wrote:
> Sandra,
>> This patch seems quite similar in purpose to the
>> remove_local_statics optimization that Mentor has proposed, although
>> the implementation is quite different. Here is the last version of
>> our patch, prepared by Bernd Schmidt
>
> H, I'm guessing this was some concern about invalid code motion
> around a setjmp. Our original analysis document lists "F does not
> call setjmp" as a requirement for the optimization, so this was
> probably a case where we were being excessively conservative.
I suppose it was because y
On 05/18/2014 02:59 PM, Jan Hubicka wrote:
Sandra,
This patch seems quite similar in purpose to the
remove_local_statics optimization that Mentor has proposed, although
the implementation is quite different. Here is the last version of
our patch, prepared by Bernd Schmidt last year:
https://gc
> > + if (!address_taken)
> > {
> > - if (dump_file)
> > + if (TREE_ADDRESSABLE (vnode->decl) && dump_file)
> > fprintf (dump_file, " %s (addressable)", vnode->name ());
>
> I know it is technically not a part of the patch... but surely this is
> supposed to dump not
Hi,
On Fri, May 16, 2014 at 07:25:59PM +0200, Jan Hubicka wrote:
>
...
>
> * varpool.c (dump_varpool_node): Dump write-only flag.
> * lto-cgraph.c (lto_output_varpool_node, input_varpool_node): Stream
> write-only flag.
> * tree-cfg.c (execute_fixup_cfg): Remove statem
Sandra,
> This patch seems quite similar in purpose to the
> remove_local_statics optimization that Mentor has proposed, although
> the implementation is quite different. Here is the last version of
> our patch, prepared by Bernd Schmidt last year:
>
> https://gcc.gnu.org/ml/gcc-patches/2013-06/m
On 05/16/2014 11:25 AM, Jan Hubicka wrote:
Hi,
this patch adds code to remove write only static variables. While analyzing
effectivity of LTO on firefox, I noticed that surprisingly large part of
binary's data segment is occupied by these. Fixed thus.
(this is quite trivial transformation, I ju
* gcc.target/ia64/visibility-1.c (variable_i): Add used attribute.
diff --git a/gcc/testsuite/gcc.target/ia64/visibility-1.c
b/gcc/testsuite/gcc.target/ia64/visibility-1.c
index fdccab3..354f081 100644
--- a/gcc/testsuite/gcc.target/ia64/visibility-1.c
+++ b/gcc/testsuite/gcc.target/ia64/
> Jan Hubicka writes:
>
> > + /* Remove stores to variables we marked readonly.
>
> s/read/write/
>
> > + /* For calls we can simply remove LHS when it is known to be read
> > only. */
>
> s/read/write/
Ah, thanks!
Honza
>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.or
Jan Hubicka writes:
> + /* Remove stores to variables we marked readonly.
s/read/write/
> + /* For calls we can simply remove LHS when it is known to be read
> only. */
s/read/write/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 17
Hi,
this patch adds code to remove write only static variables. While analyzing
effectivity of LTO on firefox, I noticed that surprisingly large part of
binary's data segment is occupied by these. Fixed thus.
(this is quite trivial transformation, I just never considered it important
enough to wo
27 matches
Mail list logo
