On Thu, May 22, 2014 at 10:38 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Thu, May 22, 2014 at 2:01 AM, Kirill Yukhin <kirill.yuk...@gmail.com> > wrote: >> Hello, >> On 20 May 08:24, H.J. Lu wrote: >>> ABI alignment should be sufficient for correctness. Bigger alignments >>> are supposed to give better performance. Can you try this patch on >>> HSW and SLM to see if it has any impact on performance? >> >> Here is perf. data of your patch. >> >> Only HSW so far >> >> HSW, 64 bits, base >> >> Test Previous Current Ratio(%) >> 400.perlbench 37.7000 37.7000 +0% >> 401.bzip2 24.8000 24.7000 -0.40% >> 403.gcc 35.1000 35.2000 +0.28% >> 429.mcf 41.7000 42.0000 +0.71% >> 445.gobmk 26.9000 27.0000 +0.37% >> 456.hmmer 27.2000 27.2000 +0% >> 458.sjeng 30.2000 30.1000 -0.33% >> 462.libquantum 77.4000 76.7000 -0.90% >> 464.h264ref 52.5000 52.8000 +0.57% >> 471.omnetpp 23.8000 23.7000 -0.42% >> 473.astar 23.2000 23.1000 -0.43% >> 483.xalancbmk 39.8000 40.1000 +0.75% >> 410.bwaves 78.4000 78.5000 +0.12% >> 416.gamess 33.9000 33.9000 +0% >> 433.milc 34.7000 34.8000 +0.28% >> 434.zeusmp 38.6000 38.4000 -0.51% >> 435.gromacs 26.9000 27.0000 +0.37% >> 436.cactusADM 54.7000 62.0000 +13.34% >> 437.leslie3d 45.3000 45.3000 +0% >> 444.namd 27.2000 27.1000 -0.36% >> 447.dealII 56.7000 56.7000 +0% >> 450.soplex 39.3000 39.3000 +0% >> 453.povray 49.0000 49.1000 +0.20% >> 454.calculix 28.8000 29.3000 +1.73% >> 459.GemsFDTD 38.9000 39.0000 +0.25% >> 465.tonto 23.1000 23.3000 +0.86% >> 470.lbm 55.3000 55.6000 +0.54% >> 481.wrf 40.8000 40.8000 +0% >> 482.sphinx3 47.8000 47.9000 +0.20% >> >> HSW, 64 bits, o2 >> >> Test Previous Current Ratio(%) >> 400.perlbench 39.7000 39.7000 +0% >> 401.bzip2 25.1000 25.1000 +0% >> 403.gcc 33.7000 33.7000 +0% >> 429.mcf 40.1000 39.9000 -0.49% >> 445.gobmk 26.5000 26.4000 -0.37% >> 456.hmmer 24.8000 24.8000 +0% >> 458.sjeng 28.4000 28.5000 +0.35% >> 462.libquantum 74.4000 74.4000 +0% >> 464.h264ref 50.1000 50.3000 +0.39% >> 471.omnetpp 22.6000 22.5000 -0.44% >> 473.astar 20.7000 21.0000 +1.44% >> 483.xalancbmk 37.0000 37.4000 +1.08% >> 410.bwaves 60.1000 60.1000 +0% >> 416.gamess 35.5000 35.4000 -0.28% >> 433.milc 29.9000 29.8000 -0.33% >> 434.zeusmp 34.8000 34.6000 -0.57% >> 435.gromacs 27.4000 27.5000 +0.36% >> 436.cactusADM 32.3000 33.8000 +4.64% >> 437.leslie3d 32.6000 32.6000 +0% >> 444.namd 26.9000 26.9000 +0% >> 447.dealII 45.2000 45.1000 -0.22% >> 450.soplex 42.5000 42.6000 +0.23% >> 453.povray 45.9000 46.1000 +0.43% >> 454.calculix 12.9000 12.9000 +0% >> 459.GemsFDTD 38.6000 38.7000 +0.25% >> 465.tonto 23.7000 23.8000 +0.42% >> 470.lbm 56.7000 56.7000 +0% >> 481.wrf 28.9000 28.9000 +0% >> 482.sphinx3 43.9000 43.8000 -0.22% >> > > So extra alignment doesn't have any performance impact > on HSW with SPEC CPU 2006. So the question is if using > alignment specified by ABI will cause any correctness issue. > I am concerned about the comment: > > /* GCC 4.8 and earlier used to incorrectly assume this alignment even > for symbols from other compilation units or symbols that don't need > to bind locally. In order to preserve some ABI compatibility with > those compilers, ensure we don't decrease alignment from what we > used to assume. */ > > Jakub, will we into any correctness issue if ix86_data_alignment > always returns ABI alignment? >
The ABI issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 That is we shouldn't use alignment beyond ABI if the definition may come from a different compilation unit. But DATA_ALIGNMENT is only for optimization purpose. I opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 for excessive x86 data alignment. It looks like that started as an accident from: https://gcc.gnu.org/ml/gcc-patches/2000-06/msg00871.html which aligned struct >= 32 bytes to 32 bytes. But alignment beyond natural alignment doesn't provide performance benefit. Should we limit DATA_ALIGNMENT to MAX (ABI alignment, natural alignment)? -- H.J.
