RFE: Get Xorg compiling with the Sun Workshop/Forte XIPO (interprocedural optimizer) option. The idea would be that the inlining and optimisation across various source files would give a significant performance boost.
Created attachment 1267 [details] [review] Prototype patch for 2004-11-09-trunk Usage: 1. Pull source: % cvs -d:pserver:anoncvs@xprint.freedesktop.org:/cvs/xorg checkout xc 2. Create xc/config/cf/host.def with the following content: -- snip -- #define HasFreetype2 NO #undef OptimizedCDebugFlags #define OptimizedCDebugFlags -xipo=2 -xipo_archive=writeback -xO4 -xbuiltin=%all -xlibmil -xstrconst -xarch=v8plus #undef OptimizedCplusplusDebugFlags #define OptimizedCplusplusDebugFlags -xipo=2 -xipo_archive=writeback -xO4 -xbuiltin=%all -xlibmil -xarch=v8plus -- snip -- 3. Start the build % timex nice make World 2>&1 | tee -a buildlog.log
I forgot one step between [2] and [3]: 2a) Apply patch (attachment #1267 [details] [review])
I tried Studio 9 compiler, and I get a linker error while building ./libOSMesa.so.4.0: ld: fatal: too many symbols require `small' PIC references: have 2112, maximum 2048 -- recompile some modules -K PIC. It's not clear whether this is due to IPO inflating the number of symbols. Roland, is this the error you get ?
Seongbae Park wrote: > I tried Studio 9 compiler, and I get a linker error while building > ./libOSMesa.so.4.0: > > ld: fatal: too many symbols require `small' PIC references: > have 2112, maximum 2048 -- recompile some modules -K PIC. Ahhrgll. No, that wasn't the error I was thinking about, but that mess is biting people from time to time. I am sick of it. I'll file a patch later which should get rid of this xx@@@!!! in libGL for the forseeable future... =:-) > It's not clear whether this is due to IPO inflating the number of symbols. > Roland, is this the error you get ? No, the problem I was thinking about was this one (the issue above is well known, the one below only happens with -xipo): -- snip -- (cd .; CC -xipo=2 -xipo_archive=writeback -xO4 -xbuiltin=%all -xlibmil -xarch=v8plus -o ./libGLU.so.1.3~ -G -z text -xipo=2 -xipo_archive=writeback -xO4 -xbuiltin=%all -xlibmil -xarch=v8plus libutil/?*.o libtess/?*.o libnurbs/internals/?*.o libnurbs/interface/?*.o libnurbs/nurbtess/?*.o -L../../exports/lib -lXext -lX11 -lGL) Text relocation remains referenced against symbol offset in file OpenGLCurveEvaluator::__BASE_TABLE__ 0x8 libnurbs/interface/glcurveval.o OpenGLCurveEvaluator::__BASE_TABLE__ 0x44 libnurbs/interface/glcurveval.o OpenGLCurveEvaluator::__BASE_TABLE__ 0x80 libnurbs/interface/glcurveval.o GLUnurbs::__BASE_TABLE__ 0x8 libnurbs/interface/glrenderer.o GLUnurbs::__BASE_TABLE__ 0x38 libnurbs/interface/glrenderer.o GLUnurbs::__BASE_TABLE__ 0x68 libnurbs/interface/glrenderer.o OpenGLSurfaceEvaluator::__BASE_TABLE__ 0x8 libnurbs/interface/glsurfeval.o OpenGLSurfaceEvaluator::__BASE_TABLE__ 0x44 libnurbs/interface/glsurfeval.o OpenGLSurfaceEvaluator::__BASE_TABLE__ 0x80 libnurbs/interface/glsurfeval.o CoveAndTiler::__BASE_TABLE__ 0x88 libnurbs/internals/coveandtiler.o Hull::__BASE_TABLE__ 0x8 libnurbs/internals/hull.o Mesher::__BASE_TABLE__ 0x68 libnurbs/internals/mesher.o NurbsTessellator::__BASE_TABLE__ 0x8 libnurbs/internals/nurbstess.o NurbsTessellator::__BASE_TABLE__ 0x40 libnurbs/internals/nurbstess.o NurbsTessellator::__BASE_TABLE__ 0x78 libnurbs/internals/nurbstess.o Slicer::__BASE_TABLE__ 0x2c libnurbs/internals/slicer.o Sorter::__BASE_TABLE__ 0x78 libnurbs/internals/sorter.o Sorter::__BASE_TABLE__ 0xa4 libnurbs/internals/sorter.o Sorter::__BASE_TABLE__ 0xd0 libnurbs/internals/sorter.o FlistSorter::__BASE_TABLE__ 0x8 libnurbs/internals/flistsorter.o FlistSorter::__BASE_TABLE__ 0x38 libnurbs/internals/flistsorter.o FlistSorter::__BASE_TABLE__ 0x6c libnurbs/internals/flistsorter.o CachingEvaluator::__BASE_TABLE__ 0x8 libnurbs/internals/cachingeval.o CachingEvaluator::__BASE_TABLE__ 0x40 libnurbs/internals/cachingeval.o CachingEvaluator::__BASE_TABLE__ 0x78 libnurbs/internals/cachingeval.o ArcSorter::__BASE_TABLE__ 0x30 libnurbs/internals/arcsorter.o ArcSorter::__BASE_TABLE__ 0x60 libnurbs/internals/arcsorter.o ArcSorter::__BASE_TABLE__ 0x90 libnurbs/internals/arcsorter.o ArcSdirSorter::__BASE_TABLE__ 0xc8 libnurbs/internals/arcsorter.o ArcSdirSorter::__BASE_TABLE__ 0xfc libnurbs/internals/arcsorter.o ArcSdirSorter::__BASE_TABLE__ 0x130 libnurbs/internals/arcsorter.o ArcTdirSorter::__BASE_TABLE__ 0x16c libnurbs/internals/arcsorter.o ArcTdirSorter::__BASE_TABLE__ 0x1a0 libnurbs/internals/arcsorter.o ArcTdirSorter::__BASE_TABLE__ 0x1d4 libnurbs/internals/arcsorter.o BasicCurveEvaluator::__BASE_TABLE__ 0x8 libnurbs/internals/basiccrveval.o BasicCurveEvaluator::__BASE_TABLE__ 0x40 libnurbs/internals/basiccrveval.o BasicCurveEvaluator::__BASE_TABLE__ 0x7c libnurbs/internals/basiccrveval.o BasicSurfaceEvaluator::__BASE_TABLE__ 0x8 libnurbs/internals/basicsurfeval.o BasicSurfaceEvaluator::__BASE_TABLE__ 0x44 libnurbs/internals/basicsurfeval.o BasicSurfaceEvaluator::__BASE_TABLE__ 0x80 libnurbs/internals/basicsurfeval.o ld: fatal: relocations remain against allocatable but non-writable sections -- snip --
Seongbae Park: I've killed the PIC-vs-pic linker issue with bug 1843 ("Link stage of libOSMesa.so.4.0 fails every couple of months with "too many symbols require `small' PIC references").
The next problem - if you skip the libGLU build failure with |#define BuildGLU NO| in xc/config/cf/host.def is: -- snip -- rm -f damage.o cc -xipo=2 -xipo_archive=writeback -xO4 -xbuiltin=%all -xlibmil -xstrconst -xarch=v8plus -Xa -v -zlazyload -zcombreloc -xstrconst -xildoff -I. -I../shadow -I../../mi -I../../fb -I../../include -I../../../../exports/include/X11 -I../../../../include/fonts -I../../../../programs/Xserver/hw/xfree86/common -I../../render -I../cw -I../../../../include/extensions -I../../../.. -I../../../../exports/include -Dsun -Dsparc -DSVR4 -D__EXTENSIONS__ -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -DXFIXES -DDAMAGE -DCOMPOSITE -DXEVIE -DINCLUDE_ALLOCA_H -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_BIG_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((8) * 100000) + ((1) * 1000) + 99)" -DNDEBUG -DIN_MODULE -DXFree86Module -c damage.c rm -f libdamage.a /usr/ccs/bin/ar cqs libdamage.a damage.o rm -f ../../../../exports/lib/modules/./libdamage.a + cd ../../../../exports/lib/modules/. + ln -s ../../../programs/Xserver/miext/damage/libdamage.a . LD_RUN_PATH=/usr/X11R6/lib cc -o Xorg -xipo=2 -xipo_archive=writeback -xO4 -xbuiltin=%all -xlibmil -xstrconst -xarch=v8plus -Xa -v -zlazyload -zcombreloc -xstrconst -xildoff -L../../exports/lib xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o ../../programs/Xserver/hw/xfree86/common/xf86Init.o ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o ../../programs/Xserver/hw/xfree86/common/libxf86.a ../../programs/Xserver/hw/xfree86/parser/libxf86config.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a ../../programs/Xserver/hw/xfree86/loader/libloader.a ../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a os/libos.a ../../lib/font/fontbase.o ../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a ../../programs/Xserver/hw/xfree86/common/libxf86.a composite/libcomposite.a damageext/libdamage.a miext/damage/libdamage.a xfixes/libxfixes.a miext/cw/libcw.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a dix/libxpstubs.a mi/libmi.a composite/libcomposite.a damageext/libdamage.a miext/damage/libdamage.a xfixes/libxfixes.a miext/cw/libcw.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lsocket -lnsl -lz -lm -lXau -lXdmcp -ldl -Wl,-z,lazyload ar: xf86noBus.o not found ar: xf86MiscExt.o not found ar: xf86VidMode.o not found ar: xf86fbman.o not found ar: xf86xv.o not found ar: xf86xvmc.o not found ar: xf86cmap.o not found ar: xf86Versions.o not found ar: xf86Debug.o not found ar: xisb.o not found ar: shape.o not found ar: agp_noop.o not found ar: kmod_noop.o not found ar: posix_tty.o not found ar: sun_bios.o not found ar: sun_mouse.o not found ar: BUSmemcpy.o not found ar: Delay.o not found ar: IODelay.o not found ar: SlowBcopy.o not found ipa_extract_section_from_elf: No such file or directory /opt/SUNWspro/prod/bin/ipo: FAILED: File open failed /tmp/libloEAAqRaqAE/xf86noBus.o *** Error code 1 make: Fatal error: Command failed for target `Xorg' Current working directory /shared/bigtmp/xorg/work001/xc/programs/Xserver *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /shared/bigtmp/xorg/work001/xc/programs *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /shared/bigtmp/xorg/work001/xc *** Error code 1 make: Fatal error: Command failed for target `World' Current working directory /shared/bigtmp/xorg/work001/xc *** Error code 1 make: Fatal error: Command failed for target `World' -- snip --
Confirmed that this is an ipo problem. The offending archives are: ../../programs/Xserver/hw/xfree86/common/libxf86.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a Xext/libexts.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a The workaround is to use -zallextract for the offending archives. i.e. surround those archives like: ... -zallextract Xext/libexts.a -zdefaultextract ....
Seongbae Park wrote: > Confirmed that this is an ipo problem. > The offending archives are: > > ../../programs/Xserver/hw/xfree86/common/libxf86.a > ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a > Xext/libexts.a > ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a > > The workaround is to use -zallextract for the offending archives. > i.e. surround those archives like: > > ... -zallextract Xext/libexts.a -zdefaultextract .... Uhm... can I use -zallextract for simply for all archives or will that cause any trouble/problems elsewhere ?
It's not likely to affect the correctness. However, it may increase the size of the final executable a bit if there's some unused objects in the archive. So there's some potential downside but my guess is it won't matter much.
Seongbae Park wrote: > It's not likely to affect the correctness. ... but what about performance - will that be affected somehow (except that bigger executables will load more slowly :) ?
Seongbae: BTW: Were you able to reproduce the libGLU issue listed in comment #4 , too ?
(In reply to comment #11) > Seongbae: > BTW: Were you able to reproduce the libGLU issue listed in comment #4 , too ? Seongbae: Beyond that question: Is the issue listed in comment #7 fixed in Sun Forte/Studio 10 ?
Regarding #7, I'll ask the responsible engineer, and update this bug. As for #4, I haven't tried - somehow I overlooked it, but it sounds like a compiler issue. I'm quite busy nowadays, and not sure when I'll be able to get back to it soon. However, if you can create a tarball to reproduce the bug, I can file a bug and let others look at the problem.
According to the engineer responsible for ipo, the fix for #6/#7 problem is NOT in Studio 10 unfortunately. The fix is already in the development version of the next release, so whatever the next version of Studio 10 will have the fix.
sunforte bug
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.