Hello,
following table compares optimization levels as -O0, -Os, -O1-3 and -Ofast.
Columns in the table include all ELF sections bigger than 5% for a binary.
Apart from that I took -O2 as a base option and I tried to disable every option
in this level. Similarly I measured impact of the res
On Tue, Jul 15, 2014 at 12:45 AM, Martin Liška wrote:
> Hello,
>following table compares optimization levels as -O0, -Os, -O1-3 and
> -Ofast. Columns in the table include all ELF sections bigger than 5% for a
> binary. Apart from that I took -O2 as a base option and I tried to disable
> every
On 07/15/2014 09:50 AM, Andrew Pinski wrote:
On Tue, Jul 15, 2014 at 12:45 AM, Martin Liška wrote:
Hello,
following table compares optimization levels as -O0, -Os, -O1-3 and
-Ofast. Columns in the table include all ELF sections bigger than 5% for a
binary. Apart from that I took -O2 as a
On Mon, Jul 14, 2014 at 10:52 PM, Prathamesh Kulkarni
wrote:
> On Mon, Jul 14, 2014 at 6:35 PM, Richard Biener
> wrote:
>> On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni
>> wrote:
>>> I was wondering if it was a good idea to implement
>>> predicate on expressions ?
>>>
>>> Sth like:
>>> (
On Mon, Jul 14, 2014 at 3:05 PM, Richard Biener
wrote:
> On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni
> wrote:
>> I was wondering if it was a good idea to implement
>> predicate on expressions ?
>>
>> Sth like:
>> (match_and_simplify
>> (op (op2:predicate @0))
>> transform)
>>
>> ins
On Tue, Jul 15, 2014 at 2:07 PM, Richard Biener
wrote:
> On Mon, Jul 14, 2014 at 10:52 PM, Prathamesh Kulkarni
> wrote:
>> On Mon, Jul 14, 2014 at 6:35 PM, Richard Biener
>> wrote:
>>> On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni
>>> wrote:
I was wondering if it was a good idea to
On Tue, Jul 15, 2014 at 2:47 PM, Prathamesh Kulkarni
wrote:
> On Tue, Jul 15, 2014 at 2:07 PM, Richard Biener
> wrote:
>> On Mon, Jul 14, 2014 at 10:52 PM, Prathamesh Kulkarni
>> wrote:
>>> On Mon, Jul 14, 2014 at 6:35 PM, Richard Biener
>>> wrote:
On Mon, Jul 14, 2014 at 12:07 PM, Pratham
On Tue, Jul 15, 2014 at 6:05 PM, Richard Biener
wrote:
> On Mon, Jul 14, 2014 at 3:05 PM, Richard Biener
> wrote:
>> On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni
>> wrote:
>>> I was wondering if it was a good idea to implement
>>> predicate on expressions ?
>>>
>>> Sth like:
>>> (match_
On Tue, Jul 15, 2014 at 6:28 PM, Richard Biener
wrote:
> On Tue, Jul 15, 2014 at 2:47 PM, Prathamesh Kulkarni
> wrote:
>> On Tue, Jul 15, 2014 at 2:07 PM, Richard Biener
>> wrote:
>>> On Mon, Jul 14, 2014 at 10:52 PM, Prathamesh Kulkarni
>>> wrote:
On Mon, Jul 14, 2014 at 6:35 PM, Richard
On Tue, Jul 15, 2014 at 6:29 PM, Prathamesh Kulkarni
wrote:
> On Tue, Jul 15, 2014 at 6:05 PM, Richard Biener
> wrote:
>> On Mon, Jul 14, 2014 at 3:05 PM, Richard Biener
>> wrote:
>>> On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni
>>> wrote:
I was wondering if it was a good idea to
> On 25 June 2014 10:26, Bingfeng Mei wrote:
> > Why is GCC code size so much bigger than LLVM? Does -Ofast have more
> > unrolling
> > on GCC? It doesn't seem increasing code size help performance (164.gzip &
> > 197.parser)
> > Is there comparisons for O2? I guess that is more useful for typic
On 15 July 2014 15:43, Jan Hubicka wrote:
> I also noticed that GCC code size is bigger for both firefox and libreoffice.
> There was some extra bloat in 4.9 compared to 4.8.
> Martin did some tests with -O2 and various flags, perhaps we could trottle
> some of -O2 optimizations.
Now that you men
> On 15 July 2014 15:43, Jan Hubicka wrote:
> > I also noticed that GCC code size is bigger for both firefox and
> > libreoffice.
> > There was some extra bloat in 4.9 compared to 4.8.
> > Martin did some tests with -O2 and various flags, perhaps we could trottle
> > some of -O2 optimizations.
>
This is not a patch review, lets move this to gcc@gcc.gnu.org.
On 15/07/2014 17:03, Roman Gareev wrote:
I've found out that int128_integer_type_node and
long_long_integer_type_node are NULL at the moment of definition of
the graphite_expression_size_type. Maybe we should use
long_long_integer_ty
Hi Eli,
Corinna has asked me to take a look at your bug report[1] on this
problem (since she has now encountered it in an Cygwin environment).
Unfortunately I am not an x86 expert so I am not really able to dig
deeply into it. But what I would recommend is filing an official gcc
bug report
Hi Gerald.
Are you still interested in the mirrors?
Thanks,
Dan & Go-Parts
-Original Message-
From: Gerald Pfeifer
Sent: Tuesday, July 08, 2014 11:52 AM
To: Dan D.
Cc: gcc@gcc.gnu.org
Subject: Re: PLEASE RE-ADD MIRRORS (small correction)
Hi Dan,
I see there is a later mail from Stev
Some useful information for the conference this weekend:
Friday, 18th July 2014, 6.30pm to 9pm
The Centre for Computing History
Rene Court
Coldhams Road
Cambridge CB1 3EW
http://www.computinghistory.org.uk/
Saturday, 19th July 2014, 7.30pm to 10.30pm
Murray Edwards College
University of Cambridg
Hi,
I am the author of a deterministic memory manager:
https://svn.boost.org/svn/boost/sandbox/block_ptr/
I just have a quick question: is it possible to overload all raw
pointers with a template "smart pointer"?
If not then I would hope this can be made possible.
Regards,
-Phil
18 matches
Mail list logo
