Let it be clear from the start this is a potshot and while those
trends aren't exactly new or specific to my code, i haven't tried to
provide anything but specific data from one of my app, on
win32/cygwin.
Primo, gcc getting much better wrt inling exacerbates the fact that
it's not as good as oth
On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
Let it be clear from the start this is a potshot and while those
trends aren't exactly new or specific to my code, i haven't tried to
provide anything but specific data from one of my app, on
win32/cygwin.
Primo, gcc getting much better wrt inling exace
On 1/28/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
> objdump -wdrfC --no-show-raw-insn $1|perl -pe 's/^\s+\w+:\s+//'|perl
> -ne 'printf "%4d\n", hex($1) if /sub\s+\$(0x\w+),%esp/'|sort -r| head
> -n 10
>
> msvc:2196 2100 1772 1692 1688 1444 1428 131
> On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
> >Let it be clear from the start this is a potshot and while those
> >trends aren't exactly new or specific to my code, i haven't tried to
> >provide anything but specific data from one of my app, on
> >win32/cygwin.
> >
> >Primo, gcc getting much bette
> On 1/28/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
> >> objdump -wdrfC --no-show-raw-insn $1|perl -pe 's/^\s+\w+:\s+//'|perl
> >> -ne 'printf "%4d\n", hex($1) if /sub\s+\$(0x\w+),%esp/'|sort -r| head
> >> -n 10
> >>
> >> msvc:2196 2100 1772 1692
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
Actually we do have one stack frame shrinking pass already. It depends
on where the bloat is comming from - we can pack (with some limitations)
memory used by structures/arrays used by different inline functions or
lexical blocks. We don't do a
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
Also having some testcases showing inlining deffects in GCC would be
very interesting for me. Now after IPA-SSA has been merged, I plan to
do some retuning of inliner for 4.3 release since a lot has changes
about properties of it's input and it
> On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >Also having some testcases showing inlining deffects in GCC would be
> >very interesting for me. Now after IPA-SSA has been merged, I plan to
> >do some retuning of inliner for 4.3 release since a lot has changes
> >about properties of it's i
char p;
int main() {
p = "";
return 0;
}
Don't you think that "" should end up in rw data?
/*
.file "t.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string ""
.text
.globl main
.type main, @function
main:
pushl %eb
On 1/28/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
char p;
int main() {
p = "";
return 0;
}
Don't you think that "" should end up in rw data?
Why? It's not writable after all.
Richard.
This is the beta release of binutils 2.17.50.0.12 for Linux, which is
based on binutils 2007 0128 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
I am not quite sure what you mean by direct inlining here. At -O2 G++
Decorating everything in sight with attribute always_inline/noinline
(flatten wasn't an option because it used to be troublesome and not as
'portable' across compilers).
I
Paul Schlie <[EMAIL PROTECTED]> wrote:
> if it has an indeterminate value [...] has no bearing on an rvalue
> access to a well defined storage location
You might think so, but that's actually not true in the C standard's
terminology. It sounds like you interpret "indeterminate value" to
mean what
Steven Bosscher wrote:
> Can you explain what went through your mind when you picked the
> tree_exp.complexity field for something implemented new... :-(
Please don't take this tone. I can't tell if you have your tongue
planted in your cheek, but if you do, it's not obvious.
It's entirely rea
tbp wrote:
> Secundo, while i very much appreciate the brand new string ops, it
> seems that on ia32 some array initialization cases where left out,
> hence i still see oodles of 'movl $0x0' when generating code for k8.
> Also those zeroings get coalesced at the top of functions on ia32, and
> i h
> tbp wrote:
>
> > Secundo, while i very much appreciate the brand new string ops, it
> > seems that on ia32 some array initialization cases where left out,
> > hence i still see oodles of 'movl $0x0' when generating code for k8.
> > Also those zeroings get coalesced at the top of functions on ia3
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> tbp wrote:
>
> > Secundo, while i very much appreciate the brand new string ops, it
> > seems that on ia32 some array initialization cases where left out,
> > hence i still see oodles of 'movl $0x0' when generating code for k8.
> > Also those z
Jan Hubicka wrote:
> I though the comment was more reffering to fact that we will happily
> generate
> movl $0x0, place1
> movl $0x0, place2
> ...
> movl $0x0, placeMillion
>
> rather than shorter
> xor %eax, %eax
> movl %eax, ...
Yes, that would be an improvement, but, as you say, at some po
Paweł Sikora wrote:
> typedef enum { X, Y } E;
> int f( E e )
> {
> switch ( e )
> {
> case X: return -1;
> case Y: return +1;
> }
> }
>
> In this example g++ produces a warning:
>
> e.cpp: In function ‘int f(E)’:
> e.cpp:9: warning: contro
> Jan Hubicka wrote:
>
> > I though the comment was more reffering to fact that we will happily
> > generate
> > movl $0x0, place1
> > movl $0x0, place2
> > ...
> > movl $0x0, placeMillion
> >
> > rather than shorter
> > xor %eax, %eax
> > movl %eax, ...
>
> Yes, that would be an improvement,
I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time.
Therefore, please do not make any checkins to the 4.1 branch after 2PM
PST. Once RC1 is uploaded, the branch will be open only for changes
which have my explicit approval, until the release.
Remember that the primary criter
On 1/28/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Certainly, if we're generating zillions of zero-initializations to
contiguous memory, rather than using memset, or an inline loop, that
seems unfortunate. Would you please file a bug report?
Because it takes, or seems to, a large function wit
> On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >I am not quite sure what you mean by direct inlining here. At -O2 G++
> Decorating everything in sight with attribute always_inline/noinline
> (flatten wasn't an option because it used to be troublesome and not as
> 'portable' across compiler
On FC6 x86_64-pc-linux-gnu with the svn trunk r121257 configured like this:
../trunk/configure --with-gmp=/usr/local --with-mpfr=/usr/local
--disable-multilib --enable-languages=c,c++,java
I am seeing this failure when bootstrapping. It worked for me last week:
/home/daney/gccsvn/native-tr
>
> On FC6 x86_64-pc-linux-gnu with the svn trunk r121257 configured like this:
>
> ../trunk/configure --with-gmp=/usr/local --with-mpfr=/usr/local
> --disable-multilib --enable-languages=c,c++,java
>
> I am seeing this failure when bootstrapping. It worked for me last week:
>
> /home/daney
Andrew Pinski wrote:
On FC6 x86_64-pc-linux-gnu with the svn trunk r121257 configured like this:
../trunk/configure --with-gmp=/usr/local --with-mpfr=/usr/local
--disable-multilib --enable-languages=c,c++,java
I am seeing this failure when bootstrapping. It worked for me last week:
/home/
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
BTW when inlining seems to make so noticeable difference, did you try to
use profile feedback?
Once a year, i try.
But then it boils down to the fact that as a programmer i have no way
to express how/where i want gcc to put its nose into. And i
Snapshot gcc-4.0-20070128 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20070128/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, 2007-01-25 at 11:26 -0800, Joe Buck wrote:
> > Also think about what kinds of presentations you'd like to hear and
> > encourage the appropriate people to submit proposals about those topics.
>
> It would be good to bring in the user perspective, for example, a
> discussion among people w
On 24 Jan 2007 09:56:55 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> Which optimization levels affect gimple?
> I've tried for a program to check what kind of gimple code you get
> with -fdump-tree-gimple and -O0 and -O3 have different results
On 1/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 01/24/07 12:44:
> check what kind of gimple code you get with -fdump-tree-gimple and
> -O0 and -O3 have different results,
>
-fdump-tree-gimple is the first dump *before* any optimizations occur.
To see the effect of al
On 1/26/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 1/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Paulo J. Matos wrote on 01/26/07 06:52:
>
> > Is the output of -fdump-tree-optimized a subset of GIMPLE?
> >
> Yes. The output is an incomplete textual representation of the GIMPLE
> fo
On 1/28/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
On 1/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Paulo J. Matos wrote on 01/24/07 12:44:
>
> > check what kind of gimple code you get with -fdump-tree-gimple and
> > -O0 and -O3 have different results,
> >
> -fdump-tree-gimple is the fir
On 1/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote on 01/26/07 07:28:
> It's after doing TER, so the statements are no longer valid GIMPLE statements.
>
Silly me. Richard's right. You want the output of -fdump-tree-uncprop.
That's the last GIMPLE dump (if my memory d
Shouldn't the compiler error out here.
The statement: p = "" should have been p = '\0';
Or does the compiler treat them as equivalent.
It seems that only characters should be assigned to char's and strings
are illegal
Ray
Richard Guenther wrote:
On 1/28/07, Denis Vlasenko <[EMAIL PROTECTED]>
On Sun, 2007-01-28 at 15:41 -0800, Ray Hurst wrote:
> Shouldn't the compiler error out here.
> The statement: p = "" should have been p = '\0';
> Or does the compiler treat them as equivalent.
>
> It seems that only characters should be assigned to char's and strings
> are illegal
Read about the
tbp wrote:
> On 1/28/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Certainly, if we're generating zillions of zero-initializations to
>> contiguous memory, rather than using memset, or an inline loop, that
>> seems unfortunate. Would you please file a bug report?
> Because it takes, or seems to,
> Paul Jarc wrote:
>> Paul Schlie wrote:
>> if it has an indeterminate value [...] has no bearing on an rvalue
>> access to a well defined storage location
>
> You might think so, but that's actually not true in the C standard's
> terminology. It sounds like you interpret "indeterminate value" to
Paul Schlie <[EMAIL PROTECTED]> wrote:
> x = x ; perfectly fine; as lvaue x clearly designates an object (no trap)
Can you cite the part of the standard that says that? The fact that
an expression designates an object does not exclude that object from
holding a trap representation. A trap repre
On Tue, 23 Jan 2007, Diego Novillo wrote:
There was some discussion on IRC that I would like to move to the
mailing list so that we get a wider discussion. There's been thoughts
about skipping 4.2 completely, or going to an extended Stage 3, etc.
Thoughts?
I believe that going forward we sho
Paul Schlie wrote:
>> Paul Jarc wrote:
>>> Paul Schlie wrote:
>>> if it has an indeterminate value [...] has no bearing on an rvalue
>>> access to a well defined storage location
>> You might think so, but that's actually not true in the C standard's
>> terminology. It sounds like you interpret "i
On Sun, Jan 28, 2007 at 10:42:07PM -, [EMAIL PROTECTED] wrote:
> Snapshot gcc-4.0-20070128 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20070128/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
It's probably time to turn off 4.0
> Paul Jarc wrote:
>> Paul Schlie <[EMAIL PROTECTED]> wrote:
>> x = x ; perfectly fine; as lvaue x clearly designates an object (no trap)
>
> Can you cite the part of the standard that says that? The fact that
> an expression designates an object does not exclude that object from
> holding a tra
Paul Schlie wrote:
>> Paul Jarc wrote:
>>> Paul Schlie <[EMAIL PROTECTED]> wrote:
>>> x = x ; perfectly fine; as lvaue x clearly designates an object (no trap)
>> Can you cite the part of the standard that says that? The fact that
>> an expression designates an object does not exclude that object
On Sun, Jan 28, 2007 at 11:02:10PM +, Paulo J. Matos wrote:
> On 24 Jan 2007 09:56:55 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >At present, as far as I know, the highest defined optimization level
> >is -O3. -ONUMBER where NUMBER > 3 is equivalent to -O3. There is no
> >particular
tbp wrote:
On 1/28/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
> objdump -wdrfC --no-show-raw-insn $1|perl -pe 's/^\s+\w+:\s+//'|perl
> -ne 'printf "%4d\n", hex($1) if /sub\s+\$(0x\w+),%esp/'|sort -r| head
> -n 10
>
> msvc:2196 2100 1772 1692 1688
Paulo J. Matos wrote on 01/28/07 18:03:
On 1/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 01/24/07 12:44:
check what kind of gimple code you get with -fdump-tree-gimple and
-O0 and -O3 have different results,
-fdump-tree-gimple is the first dump *before* any optimi
Paulo J. Matos wrote on 01/28/07 18:08:
On 1/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote on 01/26/07 07:28:
It's after doing TER, so the statements are no longer valid GIMPLE statements.
Silly me. Richard's right. You want the output of -fdump-tree-uncprop.
Tha
48 matches
Mail list logo
