Re: [GSOC] LTO dump tool project

2018-06-22 Thread Martin Liška 
On 06/18/2018 10:45 AM, Martin Jambor wrote:
> Hi,
> 
> On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I am trying to isolate the dump tool into real lto-dump tool. I have
>> started with the copy&paste of lto.c into lto-dump.c and done the
>> changes to Make-lang.in and config-lang.in suggested by Martin (patch
>> attached). However when I try to build, I get the following error:
>>
>> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>>
>> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>>
>> file or directory
>>
>> compilation terminated.
>>
>>
>> I am unable to find the missing dependencies and would be grateful for
>> suggestions on how to resolve the issue.
> 
> insn-modes.h is one of header files which are generated at build time,
> you will find it in the gcc subdirectory of your build directory (as
> opposed to the source directory).
> 
> Martin
> 

Hi.

There's patch that works for me.
Needed dependency is here:

+lto/lto-dump.o: $(LTO_EXE)

It's bit artificial, but for now it works. Please start working
on separation of dump infrastructure to lto-dump.c. You'll need
to factor out common code shared in between lto.c and lto-dump.c.

Martin
diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index 46950776dd2..7c1acdf6419 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -21,9 +21,12 @@
 
 # The name of the LTO compiler.
 LTO_EXE = lto1$(exeext)
+LTO_DUMP_EXE = lto-dump$(exeext)
 # The LTO-specific object files inclued in $(LTO_EXE).
 LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o
 lto_OBJS = $(LTO_OBJS)
+LTO_DUMP_OBJS = lto/lto-lang.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-dump.o
+lto_dump_OBJS = $(LTO_DUMP_OBJS)
 
 # this is only useful in a LTO bootstrap, but this does not work right
 # now. Should reenable after this is fixed, but only when LTO bootstrap
@@ -39,8 +42,8 @@ lto_OBJS = $(LTO_OBJS)
 
 # These hooks are used by the main GCC Makefile.  Consult that
 # Makefile for documentation.
-lto.all.cross: $(LTO_EXE)
-lto.start.encap: $(LTO_EXE)
+lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE)
+lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE)
 lto.rest.encap:
 lto.tags:
 lto.install-common:
@@ -60,7 +63,7 @@ lto.srcinfo:
 lto.install-plugin:
 
 lto.mostlyclean:
-	rm -f $(LTO_OBJS) $(LTO_EXE) lto1.fda
+	rm -f $(LTO_OBJS) $(LTO_EXE) lto1.fda $(LTO_DUMP_OBJS) $(LTO_DUMP_EXE) lto-dump.fda
 
 lto.clean:
 lto.distclean:
@@ -81,6 +84,12 @@ $(LTO_EXE): $(LTO_OBJS) $(BACKEND) $(LIBDEPS)
 	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
 		$(LTO_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
 
+$(LTO_DUMP_EXE): $(LTO_EXE) $(LTO_DUMP_OBJS) $(BACKEND) $(LIBDEPS)
+	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
+		$(LTO_DUMP_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
+
+lto/lto-dump.o: $(LTO_EXE)
+
 lto1.fda: ../prev-gcc/lto1$(exeext) ../prev-gcc/$(PERF_DATA)
 	$(CREATE_GCOV) -binary ../prev-gcc/lto1$(exeext) -gcov lto1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1
 
diff --git a/gcc/lto/config-lang.in b/gcc/lto/config-lang.in
index 0b5a846e1ca..ada21681c6a 100644
--- a/gcc/lto/config-lang.in
+++ b/gcc/lto/config-lang.in
@@ -18,7 +18,7 @@
 # .
 
 language="lto"
-compilers="lto1\$(exeext)"
+compilers="lto1\$(exeext) lto-dump\$(exeext)"
 
 gtfiles="\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c \$(srcdir)/lto/lto.c \$(srcdir)/lto/lto.h"

Re: How to get GCC on par with ICC?

2018-06-22 Thread Szabolcs Nagy 

On 11/06/18 11:05, Martin Jambor wrote:

The int rate numbers (running 1 copy only) were not too bad, GCC was
only about 2% slower and only 525.x264_r seemed way slower with GCC.
The fp rate numbers (again only 1 copy) showed a larger difference,
around 20%.  521.wrf_r was more than twice as slow when compiled with
GCC instead of ICC and 503.bwaves_r and 510.parest_r also showed
significant slowdowns when compiled with GCC vs. ICC.



Keep in mind that when discussing FP benchmarks, the used math library
can be (almost) as important as the compiler.  In the case of 481.wrf,
we found that the GCC 8 + glibc 2.26 (so the "out-of-the box" GNU)
performance is about 70% of ICC's.  When we just linked against AMD's
libm, we got to 83%. When we instructed GCC to generate calls to Intel's
SVML library and linked against it, we got to 91%.  Using both SVML and
AMD's libm, we achieved 93%.



i think glibc 2.27 should outperform amd's libm on wrf
(since i upstreamed the single precision code from
https://github.com/ARM-software/optimized-routines/ )

the 83% -> 93% diff is because gcc fails to vectorize
math calls in fortran to libmvec calls.


That means that there likely still is 7% to be gained from more clever
optimizations in GCC but the real problem is in GNU libm.  And 481.wrf
is perhaps the most extreme example but definitely not the only one.


there is no longer a problem in gnu libm for the most
common single precision calls and if things go well
then glibc 2.28 will get double precision improvements
too.

but gcc has to learn how to use libmvec in fortran.

gcc-8-20180622 is now available

2018-06-22 Thread gccadmin 
Snapshot gcc-8-20180622 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180622/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 261975

You'll find:

 gcc-8-20180622.tar.xzComplete GCC

  SHA256=d86057fefd861fc31bafbea6ac082ccd8146265f07e54c009e82f70731ad9b72
  SHA1=4acda4931a89ff38af7dab369ef69b1e20a412c6

Diffs from 8-20180615 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.