Re: [TCWG CI] 456.hmmer slowed down by 5% after llvm: Revert "Allow rematerialization of virtual reg uses"

I thought the speed up and slow-down from "Allow rematerialization of virtual reg uses" were for different benchmarks, but they are for the same benchmark — 456.hmmer — but for different compilation flags. - At -O2 the patch slows down 456.hmmer by 5% from 751s to 771s. - At -O2 -flto patch spee

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

[CCing Jeff and list for broader audience] On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: Hi Aldy, Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please take a look if this is something that could be easily fixed? First of all, thanks for chasing this down. It's incredibly us

Re: [TCWG CI] Regression caused by linux:30f349097897c115345beabeecc5e710b479ff1e

On Wed, Sep 29, 2021 at 3:41 AM Maxim Kuvyrkov wrote: > > The metric used in this CI loop is number of linux kernel object files > compiled by GCC-11. GCC-11 could compile “all” of linux kernel at last_good > revision, but only 21782 objects at first_bad. Ok, that was not clear in the report e

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

On 9/29/21 7:59 AM, Maxim Kuvyrkov wrote: Does it run like once a day/some-time-period, and if you note a regression, narrow it down? Configurations that track master branches have 3-day intervals. Configurations that track release branches — 6 days. If a regression is detected it is n

Re: test-mail

test On Thu, 30 Sept 2021 at 09:35, Prasanth Nair wrote: > test-mail > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [CI-NOTIFY]: TCWG Bisect tcwg_kernel/llvm-master-aarch64-lts-allmodconfig - Build # 6 - Successful!

Hi Greg, This appears to have been a fluke. Boot-testing succeeded before the merge and failed after. Boot-testing on allmodconfig doesn’t seem to be stable, so we are going to disable it. Regards, -- Maxim Kuvyrkov https://www.linaro.org > On 18 Aug 2021, at 08:38, Greg Kroah-Hartman > w

Re: [TCWG CI] 464.h264ref slowed down by 3% after llvm: Fix test from 8dd42f, capitalization in test

This is a fluke. The bisection is searching for an 8% regression in 464.h264ref and it tripped just above 2% threshold on this patch due to benchmarking noise. -- Maxim Kuvyrkov https://www.linaro.org > On 27 Sep 2021, at 14:42, ci_not...@linaro.org wrote: > > After llvm commit e8e2edd8ca88f8

Re: [TCWG CI] Regression caused by binutils: [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp

This is a fluke in bare-metal benchmark. Investigating. Sorry for the noise. -- Maxim Kuvyrkov https://www.linaro.org > On 27 Sep 2021, at 12:56, ci_not...@linaro.org wrote: > > [TCWG CI] Regression caused by binutils: [gdb/testsuite] Add > gdb.testsuite/dump-system-info.exp: > commit b4e4386

[TCWG CI] 464.h264ref slowed down by 3% after llvm: Fix test from 8dd42f, capitalization in test

After llvm commit e8e2edd8ca88f8b0a7dba141349b2aa83284f3af Author: Erich Keane Fix test from 8dd42f, capitalization in test the following benchmarks slowed down by more than 2%: - 464.h264ref slowed down by 3% from 10973 to 11249 perf samples - 464.h264ref:[.] FastFullPelBlockMotionSearch

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

Hi Aldy, Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please take a look if this is something that could be easily fixed? Regards, -- Maxim Kuvyrkov https://www.linaro.org > On 27 Sep 2021, at 02:52, ci_not...@linaro.org wrote: > > After gcc commit 4a960d548b7d7d942f316c

Re: [CI-NOTIFY]: TCWG Bisect tcwg_kernel/llvm-master-aarch64-next-allyesconfig - Build # 14 - Successful!

> On 3 Aug 2021, at 23:16, Nathan Chancellor wrote: > > On 8/3/2021 12:52 PM, ci_not...@linaro.org wrote: >> Successfully identified regression in *linux* in CI configuration >> tcwg_kernel/llvm-master-aarch64-next-allyesconfig. So far, this commit has >> regressed CI configurations: >> - tcw

Re: [CI-NOTIFY]: TCWG Bisect tcwg_kernel/llvm-release-aarch64-next-allnoconfig - Build # 10 - Successful!

> On 28 Jul 2021, at 01:09, Nick Desaulniers wrote: > > On Mon, Jul 26, 2021 at 6:32 PM Nathan Chancellor wrote: >> >> On 7/26/2021 6:26 PM, ci_not...@linaro.org wrote: >>> Successfully identified regression in *linux* in CI configuration >>> tcwg_kernel/llvm-release-aarch64-next-allnoconfig.

[TCWG CI] 401.bzip2 grew in size by 2% after llvm: Revert "Allow rematerialization of virtual reg uses"

After llvm commit 08d7eec06e8cf5c15a96ce11f311f1480291a441 Author: Stanislav Mekhanoshin Revert "Allow rematerialization of virtual reg uses" the following benchmarks grew in size by more than 1%: - 401.bzip2 grew in size by 2% from 46428 to 47368 bytes Below reproducer instructions can be

Re: [TCWG CI] 462.libquantum grew in size by 3% after llvm: [JumpThreading] Ignore free instructions

Hi Nikita, FYI, your patch seems to increase code-size of 462.libquantum by 3%. Would you please check if this could be easily fixed? Regards, -- Maxim Kuvyrkov https://www.linaro.org > On 27 Sep 2021, at 01:34, ci_not...@linaro.org wrote: > > After llvm commit 1e3c6fc7cb9d2ee6a5328881f95d66

Re: [TCWG CI] Regression caused by llvm: Revert "Allow rematerialization of virtual reg uses"

Hi Stanislav, The revert of your patch made LLVM compile one less object file in the linux kernel. Presumably, this is due to warning re-appearing after the revert. No need to investigate, imo. Regards, -- Maxim Kuvyrkov https://www.linaro.org > On 27 Sep 2021, at 04:11, ci_not...@linaro.or

test-mail

test-mail ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[TCWG CI] 456.hmmer slowed down by 5% after llvm: Revert "Allow rematerialization of virtual reg uses"

After llvm commit 08d7eec06e8cf5c15a96ce11f311f1480291a441 Author: Stanislav Mekhanoshin Revert "Allow rematerialization of virtual reg uses" the following benchmarks slowed down by more than 2%: - 456.hmmer slowed down by 5% from 7649 to 8028 perf samples Below reproducer instructions can

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

Also, it slightly increases code size of 450.soplex at -Os -flto: https://lists.linaro.org/pipermail/linaro-toolchain/2021-September/007883.html -- Maxim Kuvyrkov https://www.linaro.org > On 27 Sep 2021, at 15:53, Maxim Kuvyrkov wrote: > > Hi Aldy, > > Your patch seems to slow down 471.omnet

Re: [TCWG CI] 400.perlbench slowed down by 6% after llvm: [SimplifyCFG] Ignore free instructions when computing cost for folding branch to common dest

Hi Arthur, Your patch seems to be slowing down 400.perlbench by 6% — due to slow down of its hot function S_regmatch() by 14%. Could you take a look if this is easily fixable, please? Regards, -- Maxim Kuvyrkov https://www.linaro.org > On 24 Sep 2021, at 15:07, ci_not...@linaro.org wrote: >

Re: [TCWG CI] 462.libquantum grew in size by 3% after llvm: [JumpThreading] Ignore free instructions

Also, it slows down 464.h264ref by 7% at -O3 -flto: https://lists.linaro.org/pipermail/linaro-toolchain/2021-September/007882.html Regards, -- Maxim Kuvyrkov https://www.linaro.org > On 27 Sep 2021, at 15:59, Maxim Kuvyrkov wrote: > > Hi Nikita, > > FYI, your patch seems to increase code-si

Re: [TCWG CI] Regression caused by linux:30f349097897c115345beabeecc5e710b479ff1e

Hi Linus, > > Merge tag 'pm-5.15-rc1-2’ of > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > > Hmm. This is obviously a merge commit, and the last_good one is the > previous merge: > > > from (for last_good == 9c566611ac5cc7b45af943632f7a9b1b6a642991) > > so it's not clea

Re: [TCWG CI] 456.hmmer slowed down by 6% after llvm: Allow rematerialization of virtual reg uses

Hi Stanislav, Attached is a tarball with -save-temps output (pre-processed source and generated assembly) for first-bad run (your commit) and last-good run (immediate parent of your commit). -- Maxim Kuvyrkov https://www.linaro.org > On 20 Sep 2021, at 23:15, Mekhanoshin, Stanislav > wrote:

Re: [TCWG CI] 456.hmmer slowed down by 6% after llvm: Allow rematerialization of virtual reg uses

Thanks, Stanislav. I’ve looked into profile dumps, and 456.hmmer’s hot loop get several additional reloads. E.g., "ldrr1, [sp, #84]” generates 203 additional samples, which translates into 20 seconds of time just for that one instruction. See the attached profile dumps and the the screensh

Re: [TCWG CI] Regression caused by linux:30f349097897c115345beabeecc5e710b479ff1e

On Sun, Sep 12, 2021 at 8:26 PM wrote: > > Identified regression caused by > *linux:30f349097897c115345beabeecc5e710b479ff1e*: > commit 30f349097897c115345beabeecc5e710b479ff1e > Merge: 9c566611ac5c f76c87e8c337 > Author: Linus Torvalds > > Merge tag 'pm-5.15-rc1-2' of > git://git.kernel.or

[TCWG CI] 464.h264ref slowed down by 6% after llvm: Revert "Allow rematerialization of virtual reg uses"

After llvm commit 08d7eec06e8cf5c15a96ce11f311f1480291a441 Author: Stanislav Mekhanoshin Revert "Allow rematerialization of virtual reg uses" the following benchmarks slowed down by more than 2%: - 464.h264ref slowed down by 6% from 11014 to 11697 perf samples - 464.h264ref:[.] FastFullPel

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

> On 27 Sep 2021, at 19:02, Andrew MacLeod wrote: > > On 9/27/21 11:39 AM, Maxim Kuvyrkov via Gcc wrote: >>> On 27 Sep 2021, at 16:52, Aldy Hernandez wrote: >>> >>> [CCing Jeff and list for broader audience] >>> >>> On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: Hi Aldy, Your patch seems

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

> On 27 Sep 2021, at 16:52, Aldy Hernandez wrote: > > [CCing Jeff and list for broader audience] > > On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: >> Hi Aldy, >> Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please >> take a look if this is something that could be easily fixed?

Re: [TCWG CI] 456.hmmer slowed down by 6% after llvm: Allow rematerialization of virtual reg uses

Thanks, Stanislav, FWIW, it will be, probably, easier for you to just rebuild the compiler, it is an x86_64-linux-gnu -> arm-linux-gnueabihf cross. This link has the build log [1]. cmake -G Ninja ../llvm/llvm '-DLLVM_ENABLE_PROJECTS=clang;lld' -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIO

clang-aarch64-full-2stage buildbot timeout

> > On Sep 22, 2021, at 11:23, Florian Hahn > wrote: > > > > Hi, > > > > It looks like a lot of the recent builds of clang-aarch64-full-2stage are > > timing out. > > > > E.g https://lab.llvm.org/buildbot/#/builders/179/builds/1078 while checking > > out sources > > > https://lab.llvm.org/build

[TCWG CI] Regression caused by binutils: [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp

[TCWG CI] Regression caused by binutils: [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp: commit b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 Author: Tom de Vries [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp Results regressed to # reset_artifacts: -10 # build_abe binutils: -9 #

[TCWG CI] Regression caused by linux: scripts/gcc-plugins: consistently use HOSTCC

[TCWG CI] Regression caused by linux: scripts/gcc-plugins: consistently use HOSTCC: commit e554fdf7141e9edc05e7ece258f45b471af87494 Author: Ross Burton scripts/gcc-plugins: consistently use HOSTCC Results regressed to # reset_artifacts: -10 # build_abe binutils: -9 # build_abe stage1: -5 #

Re: [TCWG CI] 456.hmmer slowed down by 5% after llvm: Revert "Allow rematerialization of virtual reg uses"

Hi Stanislav, Just FYI. Your original patch improved 456.hmmer by 5%, that’s a nice speed up! -- Maxim Kuvyrkov https://www.linaro.org > On 28 Sep 2021, at 08:21, ci_not...@linaro.org wrote: > > After llvm commit 08d7eec06e8cf5c15a96ce11f311f1480291a441 > Author: Stanislav Mekhanoshin > >

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

On 9/27/21 11:39 AM, Maxim Kuvyrkov via Gcc wrote: On 27 Sep 2021, at 16:52, Aldy Hernandez wrote: [CCing Jeff and list for broader audience] On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: Hi Aldy, Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please take a look if this is so

RE: [TCWG CI] 456.hmmer slowed down by 6% after llvm: Allow rematerialization of virtual reg uses

[AMD Official Use Only] Thanks for letting me know. Some regressions are inevitable, however do you happen to have any analysis and dumps? I myself do not understand ARM ISA well... Stas -Original Message- From: Maxim Kuvyrkov Sent: Wednesday, September 15, 2021 5:52 To: Mekhanoshin,

clang-aarch64-full-2stage buildbot timeout

Hi, It looks like a lot of the recent builds of clang-aarch64-full-2stage are timing out. E.g https://lab.llvm.org/buildbot/#/builders/179/builds/1078 while checking out sources https://lab.llvm.org/buildbot/#/builders/179/builds/1076 during building stage2 Is there anything that could be done

RE: [TCWG CI] 456.hmmer slowed down by 6% after llvm: Allow rematerialization of virtual reg uses

[AMD Official Use Only] There are actually couple things worth to try if that is easy: https://reviews.llvm.org/D109077 https://reviews.llvm.org/differential/diff/374324/ Both may slightly change spill weights and then spilling pattern. Stas -Original Message- From: Mekhanoshin, Stanis

RE: [TCWG CI] 456.hmmer slowed down by 6% after llvm: Allow rematerialization of virtual reg uses

[AMD Official Use Only] Hm... I'd really like to help, but I do not think I can do anything with megabytes of code in an asm which I do not understand and tons of differences in 48 asm files. What I can see there is overall less spilling code which was the intent in the first place: hmmer has 4

Re: clang-aarch64-full-2stage buildbot timeout

> On Sep 22, 2021, at 11:23, Florian Hahn wrote: > > Hi, > > It looks like a lot of the recent builds of clang-aarch64-full-2stage are > timing out. > > E.g https://lab.llvm.org/buildbot/#/builders/179/builds/1078 while checking > out sources > https://lab.llvm.org/buildbot/#/builders/179/

gcc-linaro-6.3.1-2017.05-i686_aarch64-elf.tar.xz

I’m trying to import these files into Ds-5. After unzipping files, it still will not show up in ds-5 search. Below is the error that I keep receiving: Sent from my iPhone___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://li

RE: [TCWG CI] 456.hmmer slowed down by 6% after llvm: Allow rematerialization of virtual reg uses

[AMD Official Use Only] I assume some of the newly rematerialized instructions caused perf drops. Probably some very specific ones. I would appreciate if you could point them to me. In addition I believe I would need to have a linked or optimized bitcode to feed into llc. Stas -Original M

Re: [CI-NOTIFY]: TCWG Bisect tcwg_kernel/llvm-release-aarch64-next-allnoconfig - Build # 10 - Successful!

On Wed, Sep 29, 2021 at 4:35 AM Maxim Kuvyrkov wrote: > > > On 28 Jul 2021, at 01:09, Nick Desaulniers wrote: > > > > On Mon, Jul 26, 2021 at 6:32 PM Nathan Chancellor wrote: > >> > >> On 7/26/2021 6:26 PM, ci_not...@linaro.org wrote: > >>> Successfully identified regression in *linux* in CI con

Re: [TCWG CI] 400.perlbench slowed down by 6% after llvm: [SimplifyCFG] Ignore free instructions when computing cost for folding branch to common dest

I have a wild guess at a potential fix in the meantime: diff --cc llvm/lib/Transforms/Utils/SimplifyCFG.cpp index 3add561c66d5,3add561c66d5..bedbca9dd4b7 --- a/llvm/lib/Transforms/Utils/SimplifyCFG.cpp +++ b/llvm/lib/Transforms/Utils/SimplifyCFG.cpp @@@ -3242,9 -3242,9 +3242,9 @@@ bool llvm::FoldB

Re: [TCWG CI] 400.perlbench slowed down by 6% after llvm: [SimplifyCFG] Ignore free instructions when computing cost for folding branch to common dest

Could I get the source file with S_regmatch()? On Mon, Sep 27, 2021 at 6:07 AM Maxim Kuvyrkov wrote: > Hi Arthur, > > Your patch seems to be slowing down 400.perlbench by 6% — due to slow down > of its hot function S_regmatch() by 14%. > > Could you take a look if this is easily fixable, please?