On 08/04/2011 06:39 AM, Jan Hubicka wrote:
Also on the oriignal topic, Iknow that Mozlla folks experimented with this
switch (and I do expect it should make noticeable reducion in the hot section
footprint that is important for them). They are not using it at the moment
because of problems with t
Also on the oriignal topic, Iknow that Mozlla folks experimented with this
switch (and I do expect it should make noticeable reducion in the hot section
footprint that is important for them). They are not using it at the moment
because of problems with their bug reporting tool not being able to do
> On Wed, Aug 3, 2011 at 2:06 PM, Jan Hubicka wrote:
> >> In xalancbmk, with the partition option, most of object files have
> >> nonzero size cold sections generated. The text size of the binary is
> >> increased to 3572728 bytes from 3466790 bytes. Profiling the program
> >> using the training
On Wed, Aug 3, 2011 at 2:06 PM, Jan Hubicka wrote:
>> In xalancbmk, with the partition option, most of object files have
>> nonzero size cold sections generated. The text size of the binary is
>> increased to 3572728 bytes from 3466790 bytes. Profiling the program
>> using the training input show
> In xalancbmk, with the partition option, most of object files have
> nonzero size cold sections generated. The text size of the binary is
> increased to 3572728 bytes from 3466790 bytes. Profiling the program
> using the training input shows the following differences. With
> partitioning, number
> On 07/25/2011 06:42 AM, Xinliang David Li wrote:
>> FYI the performance impact of this option with SPEC06 (built with
>> google_46 compiler and measured on a core2 box). The base line number
>> is FDO, and ref number is FDO + reorder_with_partitioning.
>>
>> xalancbmk improves> 3.5%
>> perlben
Hi,
> The worst part is that test coverage for this feature is
> extremely poor. It's very difficult to tell if any cleanup
> in this area is likely to introduce more bugs than it fixes.
>
> After 3 days fighting with this code, I had a bit of a
> cathartic whine on IRC. I got two votes to just
On 07/27/2011 06:51 AM, Xinliang David Li wrote:
> If we could retain most of the speedups when the optimization works well
> but avoid most of the slowdown in the benchmarks that are currently hurt,
> we could improve the overall SPEC06 score. And hopefully, this would
> also be beneficial
On Mon, Jul 25, 2011 at 6:30 PM, Joern Rennecke wrote:
> Quoting Xinliang David Li :
>
>> In xalancbmk, with the partition option, most of object files have
>> nonzero size cold sections generated. The text size of the binary is
>> increased to 3572728 bytes from 3466790 bytes. Profiling the prog
Quoting Xinliang David Li :
In xalancbmk, with the partition option, most of object files have
nonzero size cold sections generated. The text size of the binary is
increased to 3572728 bytes from 3466790 bytes. Profiling the program
using the training input shows the following differences. With
In xalancbmk, with the partition option, most of object files have
nonzero size cold sections generated. The text size of the binary is
increased to 3572728 bytes from 3466790 bytes. Profiling the program
using the training input shows the following differences. With
partitioning, number of execut
On Mon, Jul 25, 2011 at 3:23 AM, Paolo Bonzini wrote:
> On 07/25/2011 06:42 AM, Xinliang David Li wrote:
>>
>> FYI the performance impact of this option with SPEC06 (built with
>> google_46 compiler and measured on a core2 box). The base line number
>> is FDO, and ref number is FDO + reorder_wit
On 07/25/2011 06:42 AM, Xinliang David Li wrote:
FYI the performance impact of this option with SPEC06 (built with
google_46 compiler and measured on a core2 box). The base line number
is FDO, and ref number is FDO + reorder_with_partitioning.
xalancbmk improves> 3.5%
perlbench improves> 1.5
FYI the performance impact of this option with SPEC06 (built with
google_46 compiler and measured on a core2 box). The base line number
is FDO, and ref number is FDO + reorder_with_partitioning.
xalancbmk improves > 3.5%
perlbench improves > 1.5%
dealII and bzip2 degrades about 1.4%.
Note the p
Quoting Richard Henderson :
Presumably your target does have at least long unconditional branches,
since otherwise one runs into a register allocation problem. If in
addition you've long unconditional branches as well as no
exception_receiver pattern, then it seems like you could completely do
On 07/19/2011 03:24 PM, Joern Rennecke wrote:
>> Andrew Pinski points out that the feature could probably be
>> equivalently implemented via outlining and function calls
>> (I assume well back at the gimple level).
>
> Function calls would mean that you'd have to deal with
> call-clobbered registe
re. http://gcc.gnu.org/ml/gcc/2011-07/msg00349.html
Richard Henderson wrote:
> After 3 days fighting with this code, I had a bit of a
> cathartic whine on IRC. I got two votes to just rip the
> whole thing out.
Add one more vote.
> Andrew Pinski points out that the feature could probably be
> e
Quoting Richard Henderson :
Andrew Pinski points out that the feature could probably be
equivalently implemented via outlining and function calls
(I assume well back at the gimple level).
Function calls would mean that you'd have to deal with
call-clobbered registers - any working size set sav
On 07/19/2011 02:42 PM, Bernd Schmidt wrote:
> On 07/19/11 23:33, Richard Henderson wrote:
>> But after pass_partition_blocks, we run into trouble. There
>> are no less than 4 other passes that add *new* crossing jumps
>> without doing *any* of the subsequent fixups for less capable
>> targets: pa
On 07/19/11 23:33, Richard Henderson wrote:
> But after pass_partition_blocks, we run into trouble. There
> are no less than 4 other passes that add *new* crossing jumps
> without doing *any* of the subsequent fixups for less capable
> targets: pass_outof_cfg_layout_mode, pass_reorder_blocks,
> pa
20 matches
Mail list logo
