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
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 the default NDK.
LTO doesn't work at all, I'm getting an ICE t
31 matches
Mail list logo
