On Wed, Aug 17, 2011 at 10:22:16AM -0700, Xinliang David Li wrote:
> On Wed, Aug 17, 2011 at 8:35 AM, Mike Hommey wrote:
> > On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote:
> >> > Maybe I have an idea as to why FDO doesn't work so well. Does the
> >> > instrumentation code suppo
On Wed, Aug 17, 2011 at 8:35 AM, Mike Hommey wrote:
> On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote:
>> > Maybe I have an idea as to why FDO doesn't work so well. Does the
>> > instrumentation code support running several times in parallel (as in,
>> > several processes with th
On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote:
> > Maybe I have an idea as to why FDO doesn't work so well. Does the
> > instrumentation code support running several times in parallel (as in,
> > several processes with the instrumented code running concurrently)?
>
> gcc suppor
On Thu, Aug 11, 2011 at 7:21 AM, Mike Hommey wrote:
> On Thu, Aug 04, 2011 at 04:05:25PM +0200, Mike Hommey wrote:
>> Hi,
>>
>> We (Mozilla) are trying to get the best of the ARM toolchain for our
>> Android build. I recently built an Android Native-code Development Kit
>> with GCC 4.6.1 and binut
On Thu, Aug 04, 2011 at 04:05:25PM +0200, Mike Hommey wrote:
> Hi,
>
> We (Mozilla) are trying to get the best of the ARM toolchain for our
> Android build. I recently built an Android Native-code Development Kit
> with GCC 4.6.1 and binutils 2.21.53, instead of GCC 4.4.3 and binutils
> 2.19 that
On 08/08/11 21:35, Jan Hubicka wrote:
>> On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka wrote:
>
> In a way I like the current scheme since it is simple and extending it
> should IMO have some good reason. We could refine -Os behaviour without
> changing current predicates to optimize
>
> I identified the libstdc++ failure as a problem when building gcc:
>
> configure:16321: /tmp/build-ndk/gcc-4.7.0/./gcc/xgcc
> -shared-libgcc -B/tmp/build-ndk/gcc-4.7.0/./gcc -nostdinc++
> -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/
> src
> -L/tmp/build-ndk/gcc-4.7.0/arm
On Mon, Aug 08, 2011 at 02:20:37PM +0200, Mike Hommey wrote:
> I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> One is bug 50022 that I filed today.
>
> Another is the following error in stlport headers:
> error: invalid use of incomplete type 'std::string {aka struct
> s
On Tue, 9 Aug 2011, Mike Hommey wrote:
This one only happens with using the -std=gnu++0x flag.
The attached preprocessed file builds fine without -std=gnu++0x, and
fails with -std=gnu++0x. Note the same original file didn't fail with
the same stlport and -std=gnu++0x with gcc 4.6.
Shorter:
c
On 9 August 2011 13:57, Mike Hommey wrote:
> On Mon, Aug 08, 2011 at 05:25:23PM +0100, Jonathan Wakely wrote:
>> On 8 August 2011 13:20, Mike Hommey wrote:
>> >
>> > I unfortunately hit several problems with gcc 4.7 (latest snapshot).
>> > One is bug 50022 that I filed today.
>> >
>> > Another is t
On Mon, Aug 08, 2011 at 05:25:23PM +0100, Jonathan Wakely wrote:
> On 8 August 2011 13:20, Mike Hommey wrote:
> >
> > I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> > One is bug 50022 that I filed today.
> >
> > Another is the following error in stlport headers:
> > error:
> On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka wrote:
> >> >
> >> > In a way I like the current scheme since it is simple and extending it
> >> > should IMO have some good reason. We could refine -Os behaviour without
> >> > changing current predicates to optimize for speed in
> >> > a) functions d
On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka wrote:
>> >
>> > In a way I like the current scheme since it is simple and extending it
>> > should IMO have some good reason. We could refine -Os behaviour without
>> > changing current predicates to optimize for speed in
>> > a) functions declared as "
On 8 August 2011 13:20, Mike Hommey wrote:
>
> I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> One is bug 50022 that I filed today.
>
> Another is the following error in stlport headers:
> error: invalid use of incomplete type 'std::string {aka struct
> std::basic_string, s
On Thu, Aug 04, 2011 at 08:51:41PM +0200, Jan Hubicka wrote:
> > +Mark who has done size optimization tuning with FDO.
> >
> > On Thu, Aug 4, 2011 at 7:05 AM, Mike Hommey wrote:
> > > Hi,
> > >
> > > We (Mozilla) are trying to get the best of the ARM toolchain for our
> > > Android build. I recen
On Mon, Aug 08, 2011 at 11:25:56AM +0200, Mike Hommey wrote:
> On Fri, Aug 05, 2011 at 09:32:05AM +0200, Richard Guenther wrote:
> > Well, but unless your training coverage is 100% all parts with no coverage
> > get optimized with -O3 instead of -Os. And I bet coverage for mozilla
> > isn't even c
On Fri, Aug 05, 2011 at 09:32:05AM +0200, Richard Guenther wrote:
> Well, but unless your training coverage is 100% all parts with no coverage
> get optimized with -O3 instead of -Os. And I bet coverage for mozilla
> isn't even close to 100%. Thus I think recommending -O3 for FDO is
> usually a b
> >
> > In a way I like the current scheme since it is simple and extending it
> > should IMO have some good reason. We could refine -Os behaviour without
> > changing current predicates to optimize for speed in
> > a) functions declared as "hot" by user and BBs in them that are not proved
> > cold
>
> In a way I like the current scheme since it is simple and extending it
> should IMO have some good reason. We could refine -Os behaviour without
> changing current predicates to optimize for speed in
> a) functions declared as "hot" by user and BBs in them that are not proved
> cold.
> b) based
Am Fri 05 Aug 2011 07:49:49 PM CEST schrieb Xinliang David Li
:
On Fri, Aug 5, 2011 at 12:32 AM, Richard Guenther
wrote:
On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
Did you try using FDO with -Os? FDO should make hot code parts
optimized similar to -O3 but leave other pieces optimi
On Fri, Aug 5, 2011 at 12:32 AM, Richard Guenther
wrote:
> On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
Did you try using FDO with -Os? FDO should make hot code parts
optimized similar to -O3 but leave other pieces optimized for size.
Using FDO with -O3 gives you the opposit
On Fri, Aug 5, 2011 at 7:40 AM, Jan Hubicka wrote:
> Am Fri 05 Aug 2011 09:32:05 AM CEST schrieb Richard Guenther
> :
>
>> On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
>
> Did you try using FDO with -Os? FDO should make hot code parts
> optimized similar to -O3 but leave other
Am Fri 05 Aug 2011 09:32:05 AM CEST schrieb Richard Guenther
:
On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
Did you try using FDO with -Os? FDO should make hot code parts
optimized similar to -O3 but leave other pieces optimized for size.
Using FDO with -O3 gives you the opposite, col
On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
>>> Did you try using FDO with -Os? FDO should make hot code parts
>>> optimized similar to -O3 but leave other pieces optimized for size.
>>> Using FDO with -O3 gives you the opposite, cold portions optimized
>>> for size while the rest is optim
> +Mark who has done size optimization tuning with FDO.
>
> On Thu, Aug 4, 2011 at 7:05 AM, Mike Hommey wrote:
> > Hi,
> >
> > We (Mozilla) are trying to get the best of the ARM toolchain for our
> > Android build. I recently built an Android Native-code Development Kit
> > with GCC 4.6.1 and bin
Did you try using FDO with -Os? FDO should make hot code parts
optimized similar to -O3 but leave other pieces optimized for size.
Using FDO with -O3 gives you the opposite, cold portions optimized
for size while the rest is optimized for speed.
FDO with -Os still optimize for size, even in hot
2011/8/4 Xinliang David Li :
> +Mark who has done size optimization tuning with FDO.
>
> On Thu, Aug 4, 2011 at 7:05 AM, Mike Hommey wrote:
>> Hi,
>>
>> We (Mozilla) are trying to get the best of the ARM toolchain for our
>> Android build. I recently built an Android Native-code Development Kit
>>
+Mark who has done size optimization tuning with FDO.
On Thu, Aug 4, 2011 at 7:05 AM, Mike Hommey wrote:
> Hi,
>
> We (Mozilla) are trying to get the best of the ARM toolchain for our
> Android build. I recently built an Android Native-code Development Kit
> with GCC 4.6.1 and binutils 2.21.53, i
On Thu, Aug 04, 2011 at 05:16:25PM +0200, Richard Guenther wrote:
> -fprofile-use enables quite some optimizations that are even off for -O3
> which are -funroll-loops and -fpeel-loops, -ftracer and -funswitch-loops.
> Those will all be increasing code-size (hopefully only for hot code pieces
> tho
On Thu, Aug 4, 2011 at 4:05 PM, Mike Hommey wrote:
> Hi,
>
> We (Mozilla) are trying to get the best of the ARM toolchain for our
> Android build. I recently built an Android Native-code Development Kit
> with GCC 4.6.1 and binutils 2.21.53, instead of GCC 4.4.3 and binutils
> 2.19 that come with
30 matches
Mail list logo
