Marcin Dalecki | 1 Feb 01:00 2005
Picon

Re: optimisation question


On 2005-02-01, at 00:43, Joe Buck wrote:
>
> Unless you've done profiling and determined that you have a critical 
> inner
> loop, it's best to optimize your code's form for readability and
> maintainability, rather than to tweak it based on a belief you haven't
> tested that compilers will "like it better".

Optimization without profiling and measurement is like swimming without
water. Code optimization can give you only linearly better results. If 
you
really want to work miracles you should look at an *much* higher 
abstraction
level. Most of micro optimization which applied 10 years ago will 
frequently
do no good those days due to changes in hardware as well. Thus caches 
for example.
Or instruction scheduling - turns out it's best done at runtime by the 
CPU
instead of the compiler. Yea. I know there is a CPU from intel 
promising miracles
by the still to be developer compiler to start working at full gear 
frequently
called Itanic. It will sink. Static code analysis just can't get you
around fundamental complexities of the underlying theory. Most stuff 
simply can't
be analyzed in reasonable time. Thus most compilers simple end up as a 
heap
of heuristics applied after each other. However the set of heuristics 
(Continue reading)

Jeffrey A Law | 1 Feb 01:29 2005
Picon

Re: tree-ssa-dom.c Bug or not?

On Mon, 2005-01-31 at 09:46 +0100, Marcin Dalecki wrote:
> Just looking at the file mentioned in the subject I have found the
> following suspicious code around line 1380:
> 
> static void
> record_cond (tree cond, tree value)
> {
>    ...
>    slot = htab_find_slot_with_hash (avail_exprs, (void *)element,
> 				   element->hash, true);
>   ...
> }
> 
> A one is passed in the form of true as the last argument to the
> above function. However this arguments seems to be of enum inert_option 
> type.
> Checking the possible values of insert_option shows that the values
> used there should read INSERT instead.
> 
> Thus we should have:
> 
>    slot = htab_find_slot_with_hash (avail_exprs, (void *)element,
> 				   element->hash, INSERT);
> 
> Instead there.
> 
> PS. I didn't prepare a patch, since applying such a patch would be more
> difficult then just looking the code in question up and changing it 
> directly
> for someone with commit permissions anyway.
(Continue reading)

Gyle Yearsley | 1 Feb 01:41 2005

Global Reload Problem

I am having a problem with the global reload. Below is a debugging dump from
the .lreg and .greg dumps for a particular insn. In the local reload insn
register 58 of the first operand is pseudo register which needs to be
reloaded. In the global reload insn register 58 has been replaced with a
stack slot. However the processor does not support a stack slot with an
offset, thus it causes the compiler to abort since it cannot match the insn.
What really needs to happen is register 58 needs to be reloaded as a hard
register and not a stack slot. How can I tell the compiler that this needs
to be a hard register? It appears that global reload does not check the
viability of this instruction since it passed global reload and fails later.

Any help would be appreciated.  

After Local Reload
(set (reg:QI 63)
        (plus:QI (mem/s:QI (plus:SI (reg:SI 58)
                                    (symbol_ref:SI ("__clz_tab"))) 
                 (reg/v:QI 51))) 12 {addqi3} 

After Global Reload
(set (reg:QI 1 r1)
        (plus:QI (reg:QI 1 r1)
                 (mem/s:QI (plus:SI (mem:SI (plus:SI (reg/f:SI 31 q60)
                                                     (const_int -10)) 
                                    (symbol_ref:SI ("__clz_tab"))) 

Thanks,

Gyle Yearsley
gyearsley <at> zilog.com
(Continue reading)

James E Wilson | 1 Feb 03:49 2005

Re: Accessing IP on IA-64 with RTL

On Mon, 2005-01-31 at 14:20, Steve Ellcey wrote:
> I don't think the existing mcount can be called after the prologue.

I took a look at glibc.  You are right.  The current assembly stub has
too many assumptions built into it.  I think it would work if we called
__mcount directly instead of via the stub, but we can't do that
apparently because it isn't exported in the linker map.  I'll have to
see if I can get modified glibc built to try this.  If we can do this
with a linker map change, then we keep backwards compatibility with
older compilers.  I don't know the hazards of changing the linker map
though.  Or maybe __mcount can be renamed to mcount, which is being
exported, and then continue using _mcount for the assembly stub.

> Here is what I have so far, it works with HP-UX based on some minimal
> testing, but is obviously broken for the existing Linux mcount
> interface.

It looks pretty reasonable.  It would be nice if we could continue
supporting the current working linux mcount code, which means continuing
to use FUNCTION_PROFILER for linux while using PROFILE_HOOK for HPUX. 
This requires making a bunch of changes conditional on the OS.  The
glibc issue may not be fixed for a while.

Meanwhile, maybe we can work around the assembly issue by modifying
FUNCTION_PROFILER to emit some unwind directives.  You don't need to
worry about that though, as it isn't needed for HPUX.

> + static GTY(()) rtx mcount_func_rtx;
> + static rtx
> + gen_mcount_func_rtx (void)
(Continue reading)

Andrew Pinski | 1 Feb 06:26 2005
Picon

Re: Compilation performance comparison of GCC 3.4.2 and GCC 4.0.0 (20050127) on MICO sources


On Jan 31, 2005, at 3:55 AM, Karel Gardas wrote:

> Hello,
>
> last comparison is here: 
> http://gcc.gnu.org/ml/gcc/2004-12/msg01157.html
>
> Please note that for this comparison I've also redone 3.4.2 testing 
> and so
> both 3.4.2 and 4.0.0 were run under same conditions. Last few 
> comparisons
> were made with the same 3.4.2 results as you might noted. Overall
> difference between old and new 3.4.2 results is about ~4% (for -O0 
> where I
> noted it), with new results being better (faster). FYI: The hardware is
> still the same, just kernel changed from 2.4.x to 2.6.x IIRC.
>
> Anyway, the results(regresssions), since overlall 4.0.0 seems to be 
> faster
> for all -O0/1/2 than 3.4.2, are:

Hmm, I notice you used a compiler from the 27th which the same day at 
which
Steven applied a patch which should have sped up -O1.  I am thinking you
were using a compiler before that because I got about a 3 seconds speed 
up
at -O1 for ir.ii (or about a 5%) after his patch was applied.

-- Pinski
(Continue reading)

H. J. Lu | 1 Feb 07:06 2005

Recent ia64 assembler change is incompatible with gcc 3.4

FYI, recent ia64 assembler changes add more unwind directive checks,
which lead to

/net/gnu/export/gnu/src/gcc-3.4/gcc/libffi/src/ia64/unix.S: Assembler
messages:
/net/gnu/export/gnu/src/gcc-3.4/gcc/libffi/src/ia64/unix.S:322: Error:
.restore outside of body region
make[6]: *** [src/ia64/unix.lo] Error 1

H.J.

Roberto Fichera | 1 Feb 10:37 2005
Picon

Re: problem cross-compiling gcc 3.4.3 from x86/linux to

At 21.09 31/01/2005, Daniel Jacobowitz wrote:
>On Mon, Jan 31, 2005 at 09:06:03PM +0100, jf wrote:
> > Roberto Fichera wrote:
> >
> > >Hi Jean-Francois,
> > >
> > >I've read your post at the gcc-help mailing list about the gcc3.4.3 cross
> > >compilation for linux/x86 to PPC604/vxWorks. Currently I've the same
> > >error,
> > >did you resolve the CPU undefined error in some way?
> > >
> > >Best regards,
> > >
> > >Roberto Fichera.
> >
> > Yes I did !
> > I remember it is a problem with multi lib...
> > I didn't really solved the problem but If you just plan to use your
> > compiler only with ppc604 I've got a dit hack that works fine :
> > In the file that cause the error (#error directive) just hard define CPU
> > and CPU_FAMILY then run make again....
> > let me know if it works (if no I'll have a look deeper into what I did)
>
>IIRC, CPU is normally defined on the command line by the VxWorks
>makefiles.  One of many quirks of building compilers for VxWorks.

The first compilation, after untar the gcc package, goes clean if I 
--enable-languages=c only.
But if I try to recompile after a make install, the compilation fails 
because fixinclude changes
(Continue reading)

Mile Davidovic | 1 Feb 11:51 2005

Triple name


Hello all

If we build mips-*-elf cross compiler is it possible to use this compiler
for processor which support mipsisa32 
(using command line switch -mips32)? I am wondering would generated source
be the same as code generated with
mipsisa32-*-elf cross compiler?

Best regards Mile

Andreas Schwab | 1 Feb 11:59 2005
Picon

Bootstrap fails in libjava

Current mainline fails to build libjava:

if /bin/sh ./libtool --mode=compile /tmp/cvs/gcc-20050201/Build/gcc/xgcc -shared-libgcc
-B/tmp/cvs/gcc-20050201/Build/gcc/ -nostdinc++
-L/tmp/cvs/gcc-20050201/Build/ia64-suse-linux/libstdc++-v3/src
-L/tmp/cvs/gcc-20050201/Build/ia64-suse-linux/libstdc++-v3/src/.libs
-B/usr/local/ia64-suse-linux/bin/ -B/usr/local/ia64-suse-linux/lib/ -isystem
/usr/local/ia64-suse-linux/include -isystem /usr/local/ia64-suse-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj  -I../../../libjava -Iinclude
-I../../../libjava/include -I../../../libjava/../boehm-gc/include -I../boehm-gc/include 
-I../../../libjava/libltdl -I../../../libjava/libltdl
-I../../../libjava/.././libjava/../gcc  -I../../../libjava/../libffi/include
-I../libffi/include  -fno-rtti -fnon-call-exceptions  -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -funwind-tables -Wextra -Wall -D_GNU_SOURCE -DPR
 EFIX="\"/usr/local\"" -DLIBDIR="\"/usr/local/lib\"" -DBOOT_CLASS_PATH="\"/usr/local/share/
 java/libgcj-4.0.0.jar\"" -DJAVA_EXT_DIRS="\"/usr/local/share/java/ext\"" -g -O2 -D_GNU_SOURCE
-MT prims.lo -MD -MP -MF "$depbase.Tpo" -c -o prims.lo ../../../libjava/prims.cc; \
then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi
/tmp/cvs/gcc-20050201/Build/gcc/xgcc -shared-libgcc -B/tmp/cvs/gcc-20050201/Build/gcc/
-nostdinc++ -L/tmp/cvs/gcc-20050201/Build/ia64-suse-linux/libstdc++-v3/src
-L/tmp/cvs/gcc-20050201/Build/ia64-suse-linux/libstdc++-v3/src/.libs
-B/usr/local/ia64-suse-linux/bin/ -B/usr/local/ia64-suse-linux/lib/ -isystem
/usr/local/ia64-suse-linux/include -isystem /usr/local/ia64-suse-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj -I../../../libjava -Iinclude
-I../../../libjava/include -I../../../libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../libjava/libltdl -I../../../libjava/libltdl
-I../../../libjava/.././libjava/../gcc -I../../../libjava/../libffi/include
-I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -funwind-tables -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/local\" -DLIBDIR=\"/usr/local
 /lib\" -DBOOT_CLASS_PATH=\"/usr/local/share/java/libgcj-4.0.0.jar\" -DJAVA_EXT_DIRS=\"/usr
(Continue reading)

Ranjit Mathew | 1 Feb 13:30 2005
Picon

Re: Bootstrap fails in libjava

Andreas Schwab wrote:
> Current mainline fails to build libjava:

Revert gcc/java/gjavah.c to revision 1.124:

http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gjavah.c.diff?r1=1.124&r2=1.125

Works for me (i686-pc-linux-gnu).

Thanks,
Ranjit.

> if /bin/sh ./libtool --mode=compile /tmp/cvs/gcc-20050201/Build/gcc/xgcc -shared-libgcc
-B/tmp/cvs/gcc-20050201/Build/gcc/ -nostdinc++
-L/tmp/cvs/gcc-20050201/Build/ia64-suse-linux/libstdc++-v3/src
-L/tmp/cvs/gcc-20050201/Build/ia64-suse-linux/libstdc++-v3/src/.libs
-B/usr/local/ia64-suse-linux/bin/ -B/usr/local/ia64-suse-linux/lib/ -isystem
/usr/local/ia64-suse-linux/include -isystem /usr/local/ia64-suse-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj  -I../../../libjava -Iinclude
-I../../../libjava/include -I../../../libjava/../boehm-gc/include -I../boehm-gc/include 
-I../../../libjava/libltdl -I../../../libjava/libltdl
-I../../../libjava/.././libjava/../gcc  -I../../../libjava/../libffi/include
-I../libffi/include  -fno-rtti -fnon-call-exceptions  -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -funwind-tables -Wextra -Wall -D_GNU_SOURCE -D
 PR
>  EFIX="\"/usr/local\"" -DLIBDIR="\"/usr/local/lib\"" -DBOOT_CLASS_PATH="\"/usr/local/share/
>  java/libgcj-4.0.0.jar\"" -DJAVA_EXT_DIRS="\"/usr/local/share/java/ext\"" -g -O2 -D_GNU_SOURCE
-MT prims.lo -MD -MP -MF "$depbase.Tpo" -c -o prims.lo ../../../libjava/prims.cc; \
> then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi
> /tmp/cvs/gcc-20050201/Build/gcc/xgcc -shared-libgcc -B/tmp/cvs/gcc-20050201/Build/gcc/
(Continue reading)


Gmane