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

[Aldy Hernandez via Gcc]

[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 useful to 
have these types of bug reports.


Jeff and I have been discussing the repercussions of adjusting the loop 
crossing restrictions in the various threaders.  He's seen some 
regressions in embedded targets when disallowing certain corner cases of 
loop crossing threads causes all sorts of grief.


Out of curiosity, does the attached (untested) patch fix the regression?

Aldy



Regards,

--
Maxim Kuvyrkov
https://www.linaro.org


On 27 Sep 2021, at 02:52, ci_not...@linaro.org wrote:

After gcc commit 4a960d548b7d7d942f316c5295f6d849b74214f5
Author: Aldy Hernandez 

Avoid invalid loop transformations in jump threading registry.

the following benchmarks slowed down by more than 2%:
- 471.omnetpp slowed down by 8% from 6348 to 6828 perf samples

Below reproducer instructions can be used to re-build both "first_bad" and 
"last_good" cross-toolchains used in this bisection.  Naturally, the scripts will fail 
when triggerring benchmarking jobs if you don't have access to Linaro TCWG CI.

For your convenience, we have uploaded tarballs with pre-processed source and 
assembly files at:
- First_bad save-temps: 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-4a960d548b7d7d942f316c5295f6d849b74214f5/save-temps/
- Last_good save-temps: 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-29c92857039d0a105281be61c10c9e851aaeea4a/save-temps/
- Baseline save-temps: 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-baseline/save-temps/

Configuration:
- Benchmark: SPEC CPU2006
- Toolchain: GCC + Glibc + GNU Linker
- Version: all components were built from their tip of trunk
- Target: arm-linux-gnueabihf
- Compiler flags: -O3 -marm
- Hardware: NVidia TK1 4x Cortex-A15

This benchmarking CI is work-in-progress, and we welcome feedback and suggestions at 
linaro-toolch...@lists.linaro.org .  In our improvement plans is to add support for SPEC 
CPU2017 benchmarks and provide "perf report/annotate" data behind these reports.

THIS IS THE END OF INTERESTING STUFF.  BELOW ARE LINKS TO BUILDS, REPRODUCTION 
INSTRUCTIONS, AND THE RAW COMMIT.

This commit has regressed these CI configurations:
- tcwg_bmk_gnu_tk1/gnu-master-arm-spec2k6-O3

First_bad build: 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-4a960d548b7d7d942f316c5295f6d849b74214f5/
Last_good build: 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-29c92857039d0a105281be61c10c9e851aaeea4a/
Baseline build: 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-baseline/
Even more details: 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/

Reproduce builds:

mkdir investigate-gcc-4a960d548b7d7d942f316c5295f6d849b74214f5
cd investigate-gcc-4a960d548b7d7d942f316c5295f6d849b74214f5

# Fetch scripts
git clone https://git.linaro.org/toolchain/jenkins-scripts

# Fetch manifests and test.sh script
mkdir -p artifacts/manifests
curl -o artifacts/manifests/build-baseline.sh 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/manifests/build-baseline.sh
 --fail
curl -o artifacts/manifests/build-parameters.sh 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/manifests/build-parameters.sh
 --fail
curl -o artifacts/test.sh 
https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/test.sh
 --fail
chmod +x artifacts/test.sh

# Reproduce the baseline build (build all pre-requisites)
./jenkins-scripts/tcwg_bmk-build.sh @@ artifacts/manifests/build-baseline.sh

# Save baseline build state (which is then restored in artifacts/test.sh)
mkdir -p ./bisect
rsync -a --del --delete-excluded --exclude /bisect/ --exclude /artifacts/ 
--exclude /gcc/ ./ ./bisect/baseline/

cd gcc

# Reproduce first_bad build
git checkout --detach 4a960d548b7d7d942f316c5295f6d849b74214f5
../artifacts/test.sh

# Reproduce last_good build
git checkout --detach 29c92857039d0a105281be61c10c9e851aaeea4a
../artifacts/test.sh

cd ..


Full commit (up to 1000 lines):

commit 4a960d548b7d7d942f316c5295f6d849b74214f5
Author: Aldy Hernandez 
Date:   Thu Sep 23 10:59:24 2021 +0200

Avoid invalid loop transformations in jump threading registry.

My upcoming improvements to the forward jump threade

how can I contribute to your organisation

[Aditya Saini]

Hey ,I am Aditya saini  and I can code in c/c++  .I want to be a part of your 
organization so please guide me how can I contribute to your organization .
Thank you

Sent from Mail for Windows

GCC Register Pressure BoF notes

[David Edelsohn via Gcc]

Richi and Aaron,

Thanks for the great conversation about register pressure at the GCC
BoF at LPC2021.  It was a very productive session with good ideas
about how to proceed.

Where do you suggest that I place the Register pressure BoF notes?
GCC Wiki?  Email it to the GCC mailing list?  Bugzilla?  I'm not
certain where and how we want the conversation to continue.

Thanks, David

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

[Maxim Kuvyrkov via Gcc]

> 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?
> 
> First of all, thanks for chasing this down.  It's incredibly useful to have 
> these types of bug reports.

Thanks, Aldy, this is music to my ears :-).

We have built this automated benchmarking CI that bisects code-speed and 
code-size regressions down to a single commit.  It is still work-in-progress, 
and I’m forwarding these reports to patch authors, whose patches caused 
regressions.  If GCC community finds these useful, we can also setup posting to 
one of GCC’s mailing lists.

> 
> Jeff and I have been discussing the repercussions of adjusting the loop 
> crossing restrictions in the various threaders.  He's seen some regressions 
> in embedded targets when disallowing certain corner cases of loop crossing 
> threads causes all sorts of grief.
> 
> Out of curiosity, does the attached (untested) patch fix the regression?

I’ll test the patch and will follow up.

Regards,

--
Maxim Kuvyrkov
https://www.linaro.org


> 
> Aldy
> 
>> Regards,
>> --
>> Maxim Kuvyrkov
>> https://www.linaro.org
>>> On 27 Sep 2021, at 02:52, ci_not...@linaro.org wrote:
>>> 
>>> After gcc commit 4a960d548b7d7d942f316c5295f6d849b74214f5
>>> Author: Aldy Hernandez 
>>> 
>>>Avoid invalid loop transformations in jump threading registry.
>>> 
>>> the following benchmarks slowed down by more than 2%:
>>> - 471.omnetpp slowed down by 8% from 6348 to 6828 perf samples
>>> 
>>> Below reproducer instructions can be used to re-build both "first_bad" and 
>>> "last_good" cross-toolchains used in this bisection.  Naturally, the 
>>> scripts will fail when triggerring benchmarking jobs if you don't have 
>>> access to Linaro TCWG CI.
>>> 
>>> For your convenience, we have uploaded tarballs with pre-processed source 
>>> and assembly files at:
>>> - First_bad save-temps: 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-4a960d548b7d7d942f316c5295f6d849b74214f5/save-temps/
>>> - Last_good save-temps: 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-29c92857039d0a105281be61c10c9e851aaeea4a/save-temps/
>>> - Baseline save-temps: 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-baseline/save-temps/
>>> 
>>> Configuration:
>>> - Benchmark: SPEC CPU2006
>>> - Toolchain: GCC + Glibc + GNU Linker
>>> - Version: all components were built from their tip of trunk
>>> - Target: arm-linux-gnueabihf
>>> - Compiler flags: -O3 -marm
>>> - Hardware: NVidia TK1 4x Cortex-A15
>>> 
>>> This benchmarking CI is work-in-progress, and we welcome feedback and 
>>> suggestions at linaro-toolch...@lists.linaro.org .  In our improvement 
>>> plans is to add support for SPEC CPU2017 benchmarks and provide "perf 
>>> report/annotate" data behind these reports.
>>> 
>>> THIS IS THE END OF INTERESTING STUFF.  BELOW ARE LINKS TO BUILDS, 
>>> REPRODUCTION INSTRUCTIONS, AND THE RAW COMMIT.
>>> 
>>> This commit has regressed these CI configurations:
>>> - tcwg_bmk_gnu_tk1/gnu-master-arm-spec2k6-O3
>>> 
>>> First_bad build: 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-4a960d548b7d7d942f316c5295f6d849b74214f5/
>>> Last_good build: 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-29c92857039d0a105281be61c10c9e851aaeea4a/
>>> Baseline build: 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/build-baseline/
>>> Even more details: 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/
>>> 
>>> Reproduce builds:
>>> 
>>> mkdir investigate-gcc-4a960d548b7d7d942f316c5295f6d849b74214f5
>>> cd investigate-gcc-4a960d548b7d7d942f316c5295f6d849b74214f5
>>> 
>>> # Fetch scripts
>>> git clone https://git.linaro.org/toolchain/jenkins-scripts
>>> 
>>> # Fetch manifests and test.sh script
>>> mkdir -p artifacts/manifests
>>> curl -o artifacts/manifests/build-baseline.sh 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/manifests/build-baseline.sh
>>>  --fail
>>> curl -o artifacts/manifests/build-parameters.sh 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/manifests/build-parameters.sh
>>>  --fail
>>> curl -o artifacts/test.sh 
>>> https://ci.linaro.org/job/tcwg_bmk_ci_gnu-bisect-tcwg_bmk_tk1-gnu-master-arm-spec2k6-O3/40/artifact/artifacts/test.sh
>>>  --fail
>>> chmod +x artifacts/

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

[Andrew MacLeod via Gcc]

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 something that could be easily fixed?

First of all, thanks for chasing this down.  It's incredibly useful to have 
these types of bug reports.

Thanks, Aldy, this is music to my ears :-).

We have built this automated benchmarking CI that bisects code-speed and 
code-size regressions down to a single commit.  It is still work-in-progress, 
and I’m forwarding these reports to patch authors, whose patches caused 
regressions.  If GCC community finds these useful, we can also setup posting to 
one of GCC’s mailing lists.


I second that this sort of thing is incredibly useful.   I don't suppose 
its easy to do the reverse?... let patch authors know when they've 
caused a significant improvement? :-)  That would be much less common I 
suspect, so perhaps not worth it :-)


Its certainly very useful when we are making a wholesale change to a 
pass which we think is beneficial, but aren't sure.


And a followup question...  Sometimes we have no good way of determining 
the widespread run-time effects of a change.  You seem to be running 
SPEC/other things continuously then?   Does it run like once a 
day/some-time-period, and if you note a regression, narrow it down?  
Regardless, I think it could be very useful to be able to see the 
results of anything you do run at whatever frequency it happens.

Re: how can I contribute to your organisation

[Jason Merrill via Gcc]

On Mon, Sep 27, 2021 at 9:54 AM Aditya Saini 
wrote:

> Hey ,I am Aditya saini  and I can code in c/c++  .I want to be a part of
> your organization so please guide me how can I contribute to your
> organization .
>

There's a lot of information at

https://gcc.gnu.org/contribute.html

Let us know if anything is unclear.

Jason

Can gcc itself be tested with ubsan? If so, how?

[Gary Oblock via Gcc]

I tried just adding "-fsanitize=undefined" to my CXX_FLAGS and got
a bunch of errors like this:

/usr/bin/ld: ../libcody/libcody.a(server.o): in function 
`std::__cxx11::basic_string, std::allocator 
>::_Alloc_hider::~_Alloc_hider()':
/usr/include/c++/9/bits/basic_string.h:150: undefined reference to 
`__ubsan_handle_type_mismatch_v1'

They all seemed library related.

Can ubsan be used on the compiler itself?

Thanks,

Gary




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

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

[Jeff Law via Gcc]

On 9/27/2021 7:52 AM, 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?


First of all, thanks for chasing this down.  It's incredibly useful to 
have these types of bug reports.


Jeff and I have been discussing the repercussions of adjusting the 
loop crossing restrictions in the various threaders.  He's seen some 
regressions in embedded targets when disallowing certain corner cases 
of loop crossing threads causes all sorts of grief.


Out of curiosity, does the attached (untested) patch fix the regression?
And just a note, that patch doesn't seem to fix the regressions on 
visium or rl78.    I haven't checked any of the other regressing targets 
yet.


jeff

Re: GCC Register Pressure BoF notes

[Richard Biener via Gcc]

On Mon, Sep 27, 2021 at 5:08 PM David Edelsohn  wrote:
>
> Richi and Aaron,
>
> Thanks for the great conversation about register pressure at the GCC
> BoF at LPC2021.  It was a very productive session with good ideas
> about how to proceed.
>
> Where do you suggest that I place the Register pressure BoF notes?
> GCC Wiki?  Email it to the GCC mailing list?  Bugzilla?  I'm not
> certain where and how we want the conversation to continue.

It makes sense to put it on the WiKi (for archival and editing) as
well as posting to gcc@ in case
somebody wants to followup the discussion.

Richard.

> Thanks, David

Re: Can gcc itself be tested with ubsan? If so, how?

[Erick Ochoa via Gcc]

Hi,

just as a note. This is also of interest to me. I have wanted to
compile a single pass that I wrote using ubsan/other sanitizers for
testing purposes. I was wondering if someone has already modified the
build system to use ubsan to test their passes and if they could
document the process for doing so. For these purposes, I don't really
care if it can be done only without bootstrapping. I haven't
investigated enough to find out if it is possible, but I suspect it is
and may have already been done.

Thanks!

On Tue, 28 Sept 2021 at 01:01, Gary Oblock via Gcc  wrote:
>
> I tried just adding "-fsanitize=undefined" to my CXX_FLAGS and got
> a bunch of errors like this:
>
> /usr/bin/ld: ../libcody/libcody.a(server.o): in function 
> `std::__cxx11::basic_string, 
> std::allocator >::_Alloc_hider::~_Alloc_hider()':
> /usr/include/c++/9/bits/basic_string.h:150: undefined reference to 
> `__ubsan_handle_type_mismatch_v1'
>
> They all seemed library related.
>
> Can ubsan be used on the compiler itself?
>
> Thanks,
>
> Gary
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: Can gcc itself be tested with ubsan? If so, how?

[Toon Moene]

On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote:


Can ubsan be used on the compiler itself?


I regularly build the compiler(s) natively with ubsan enabled, see for 
instance:


https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/719448.html

The configure line tells you how to do it (towards the end of the mail):

configure flags: --prefix=/home/toon/compilers/install/gcc --with-gnu-as 
--with-gnu-ld --enable-languages=all,ada --disable-multilib 
--disable-nls --with-build-config=bootstrap-ubsan --enable-checking=all


(the enable-checking part is not relevant, and can be omitted).

Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands