[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #16 from Stefan Schulze Frielinghaus --- Fixed in mainline. Fine for me to close this now.
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #15 from CVS Commits ---
The master branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:452db716d8debb6e09b85e4a0c0e73a047ed5c1d
commit r13-5964-g452db716d8debb6e09b85e4a0c0e73a047ed5c1d
Author: Stefan Schulze Frielinghaus
Date: Mon Feb 13 15:33:38 2023 +0100
IBM zSystems: Do not propagate scheduler state across basic blocks
[PR108102]
So far we propagate scheduler state across basic blocks within EBBs and
reset the state otherwise. In certain circumstances the entry block of
an EBB might be empty, i.e., no_real_insns_p is true. In those cases
scheduler state is not reset and subsequently wrong state is propagated
to following blocks of the same EBB.
Since the performance benefit of tracking state across basic blocks is
questionable on modern hardware, simply reset the state for each basic
block.
Fix also resetting f{p,x}d_longrunning.
gcc/ChangeLog:
PR target/108102
* config/s390/s390.cc (s390_bb_fallthru_entry_likely): Remove.
(struct s390_sched_state): Initialise to zero.
(s390_sched_variable_issue): For better debuggability also emit
the current side.
(s390_sched_init): Unconditionally reset scheduler state.
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #14 from Stefan Schulze Frielinghaus --- I'm still working on this and currently test a new patch which should fix the scheduler handling in the backend.
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #13 from Matthias Klose --- this isn't seen anymore with current trunk. close as worksforme?
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #12 from Stefan Schulze Frielinghaus --- The culprit seems to be that s390_sched_init is not called in one particular case. We have the following basic blocks and edges: 6 --> 12 --> 13 --> 14 The edges from 12 to 13 and 13 to 14 are fall-through edges which means in function s390_sched_init we "inherit" last_scheduled_unit_distance from the previous block, i.e., we do not zero it. The edge from 6 to 12 is a non-fall-through edge which means if we schedule bb 12, then s390_sched_init will be called and last_scheduled_unit_distance will be zeroed. The culprit seems to be that bb 12 is empty if no debug information is generated or in case debug information is generated then it contains only debug insns. Thus, in the non-debug case when bb 12 is empty it is never scheduled and therefore s390_sched_init is never called and therefore last_scheduled_unit_distance is never zeroed. We also see this once inspecting last_scheduled_unit_distance at the very beginning of function schedule_block for bb 13 where we have: non-debug: 2 2 0 2 34 0 34 29 debug: 0 0 0 0 0 0 0 0 In the debug-case we "inherit" for bb 13 from bb 12 last_scheduled_unit_distance which got cleared once bb 12 was scheduled. In the non-debug case we also "inherit" the array but it did not get cleared in bb 12 because it was never scheduled.
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #11 from Stefan Schulze Frielinghaus ---
Please find attached a reduced version of the initial problem. If compiled
with
g++ -O2 -march=arch13 -fno-exceptions (-g)
there is still a difference whether build with debug information or not:
diff <(objdump -d reduced.o-without-debug) <(objdump -d reduced.o-with-debug)
2c2
< reduced.o-without-debug: file format elf64-s390
---
> reduced.o-with-debug: file format elf64-s390
94,97c94,97
< 1b8: e5 48 f0 a8 00 00 mvghi 168(%r15),0
< 1be: e3 50 f0 c8 00 04 lg %r5,200(%r15)
< 1c4: 41 30 f0 a0 la %r3,160(%r15)
< 1c8: e3 50 f0 a0 00 24 stg %r5,160(%r15)
---
> 1b8: e3 50 f0 c8 00 04 lg %r5,200(%r15)
> 1be: e5 48 f0 a8 00 00 mvghi 168(%r15),0
> 1c4: e3 50 f0 a0 00 24 stg %r5,160(%r15)
> 1ca: 41 30 f0 a0 la %r3,160(%r15)
The corresponding insns are:
Without debug information:
mvghi => insn 207
lg=> insn 206
la=> insn 310
stg => insn 312
With debug information:
lg=> insn 427
mvghi => insn 428
stg => insn 533
la=> insn 531
In split3 the order of the insns are the same and change in sched2 where we
have:
Without debug information:
;; ==
;; -- basic block 14 from 87 to 355 -- after reload
;; ==
;;0--> b 0: i 87 %r2=0 :nothing
;;1--> b 0: i 88 {%r2=call
[`_ZN4Rust4TyTy9ParamType7resolveEv'];clobber %r14;}:nothing
;;2--> b 0: i 207 [%r15+0xa8]=0 :nothing
;;3--> b 0: i 206 %r5=[%r15+0xc8] :nothing
;;4--> b 0: i 310 %r3=%r15+0xa0 :nothing
;;5--> b 0: i 312 [%r15+0xa0]=%r5 :nothing
;;6--> b 0: i 311 %r2=%r15+0xc0 :nothing
;;7--> b 0: i 96 {call
[`_ZNSt6vectorIPN4Rust4TyTy8BaseTypeESaIS3_EE17_M_realloc_insertIN9__gnu_cxx17__normal_iteratorIPS3_S5_vT_'];clobber
%r14;}:nothing
;;8--> b 0: i 355 pc=L174 :nothing
;; Ready list (final):
;; total time = 8
;; new head = 87
;; new tail = 355
With debug information:
;; ==
;; -- basic block 14 from 201 to 585 -- after reload
;; ==
;;0--> b 0: i 201 debug_marker:nothing
;;0--> b 0: i 202 %r2=0 :nothing
;;1--> b 0: i 203 {%r2=call
[`_ZN4Rust4TyTy9ParamType7resolveEv'];clobber %r14;}:nothing
;;1--> b 0: i 204 debug_marker:nothing
;;1--> b 0: i 205 loc %r15+0xc0 :nothing
;;1--> b 0: i 206 debug_marker:nothing
;;1--> b 0: i 207 loc %r15+0xc0 :nothing
;;1--> b 0: i 208 debug_marker:nothing
;;1--> b 0: i 210 loc debug_implicit_ptr :nothing
;;1--> b 0: i 211 loc [%r15+0xc8] :nothing
;;1--> b 0: i 212 debug_marker:nothing
;;1--> b 0: i 214 loc clobber :nothing
;;1--> b 0: i 215 loc clobber :nothing
;;1--> b 0: i 216 loc clobber :nothing
;;2--> b 0: i 427 %r5=[%r15+0xc8] :nothing
;;3--> b 0: i 428 [%r15+0xa8]=0 :nothing
;;4--> b 0: i 533 [%r15+0xa0]=%r5 :nothing
;;5--> b 0: i 531 %r3=%r15+0xa0 :nothing
;;6--> b 0: i 532 %r2=%r15+0xc0 :nothing
;;7--> b 0: i 222 {call
[`_ZNSt6vectorIPN4Rust4TyTy8BaseTypeESaIS3_EE17_M_realloc_insertIN9__gnu_cxx17__normal_iteratorIPS3_S5_vT_'];clobber
%r14;}:nothing
;;7--> b 0: i 223 loc clobber :nothing
;;8--> b 0: i 585 pc=L373 :nothing
;; Ready list (final):
;; total time = 8
;; new head = 201
;; new tail = 585
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #10 from Stefan Schulze Frielinghaus --- Created attachment 54279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54279=edit RTL dump of sched2 if compiled with debug information
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #9 from Stefan Schulze Frielinghaus --- Created attachment 54278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54278=edit RTL dump of sched2 if compiled without debug information
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #8 from Stefan Schulze Frielinghaus --- Created attachment 54277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54277=edit reduced version of the initial problem
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #7 from Stefan Schulze Frielinghaus --- The difference in the assembly output shown in comment 2 happens in function void AssociatedImplTrait::setup_associated_types ( const TyTy::BaseType *self, const TyTy::TypeBoundPredicate )
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #6 from Stefan Schulze Frielinghaus --- Created attachment 54154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54154=edit preprocessed rust-hir-trait-resolve.cc
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #5 from Andrew Pinski --- (In reply to Stefan Schulze Frielinghaus from comment #4) > and the current working directory was most likely /devel/gcc/build/gcc. > Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then > running the command from above doesn't do the trick. There is probably an > easier way which I miss. Any hints? See stage2-start/stage3-start I think. See https://gcc.gnu.org/onlinedocs/gccint/Makefile.html#Makefile
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #4 from Stefan Schulze Frielinghaus --- I was playing around with this and was wondering how can I actually execute the stageN compiler? From the output of make I see two compilations for object rust-hir-trait-resolve.o. Thus the first one must be for stage2 and the second one for stage3. For the former the command line is /devel/gcc/build/./prev-gcc/xg++ -B/devel/gcc/build/./prev-gcc/ -B/devel/gcc/dst/s390x-ibm-linux-gnu/bin/ -nostdinc++ -B/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/src/.libs -B/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs -I/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/include/s390x-ibm-linux-gnu -I/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/include -I/devel/gcc/src/libstdc++-v3/libsupc++ -L/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/src/.libs -L/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wno-unused-parameter -fno-common -DHAVE_CONFIG_H -I. -Irust -I/devel/gcc/src/gcc -I/devel/gcc/src/gcc/rust -I/devel/gcc/src/gcc/../include -I/devel/gcc/src/gcc/../libcpp/include -I/devel/gcc/src/gcc/../libcody -I/devel/gcc/src/gcc/../libdecnumber -I/devel/gcc/src/gcc/../libdecnumber/dpd -I../libdecnumber -I/devel/gcc/src/gcc/../libbacktrace -o rust/rust-hir-trait-resolve.o -MT rust/rust-hir-trait-resolve.o -MMD -MP -MF rust/.deps/rust-hir-trait-resolve.TPo -g -O2 -fno-checking -gtoggle -I /devel/gcc/src/gcc/rust -I /devel/gcc/src/gcc/rust/lex -I /devel/gcc/src/gcc/rust/parse -I /devel/gcc/src/gcc/rust/ast -I /devel/gcc/src/gcc/rust/analysis -I /devel/gcc/src/gcc/rust/backend -I /devel/gcc/src/gcc/rust/expand -I /devel/gcc/src/gcc/rust/hir/tree -I /devel/gcc/src/gcc/rust/hir -I /devel/gcc/src/gcc/rust/resolve -I /devel/gcc/src/gcc/rust/util -I /devel/gcc/src/gcc/rust/typecheck -I /devel/gcc/src/gcc/rust/checks/lints -I /devel/gcc/src/gcc/rust/checks/errors -I /devel/gcc/src/gcc/rust/checks/errors/privacy -I /devel/gcc/src/gcc/rust/util -I /devel/gcc/src/gcc/rust/metadata /devel/gcc/src/gcc/rust/typecheck/rust-hir-trait-resolve.cc and the current working directory was most likely /devel/gcc/build/gcc. Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then running the command from above doesn't do the trick. There is probably an easier way which I miss. Any hints?
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #3 from Andrew Pinski --- Moved to middle-end since the code that is causing issues is c++ code. Can you attach the preprocessed source? I wonder if this is a -g0 vs -g issue ...
