public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu @ 2023-07-09 15:07 doko at gcc dot gnu.org 2023-07-10 6:42 ` [Bug target/110606] " rguenth at gcc dot gnu.org ` (10 more replies) 0 siblings, 11 replies; 12+ messages in thread From: doko at gcc dot gnu.org @ 2023-07-09 15:07 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 Bug ID: 110606 Summary: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- [forwarded from https://bugs.debian.org/1040444] seen with 10, 11, 12, 13 and trunk, building firefox. $ cat Unified_cpp_gfx_skia17.ii struct SkSTArray { int *begin(); int *end(); }; static void *AllocMemory(); struct IRNode { void *operator new(unsigned long) { return AllocMemory(); } }; struct SwitchCase : IRNode { static void MakeDefault() { new SwitchCase(true, 0); } SwitchCase(bool, int); }; SkSTArray __trans_tmp_3; void inlineStatement() { for (int switchCaseStmt : __trans_tmp_3) SwitchCase::MakeDefault(); } static thread_local int *sMemPool; int set_thread_local_memory_pool_memPool; void detachFromThread() { sMemPool = &set_thread_local_memory_pool_memPool; } long AllocMemory_size; void *AllocMemory() { void *__trans_tmp_2; if (sMemPool) { __trans_tmp_2 = operator new(AllocMemory_size); return __trans_tmp_2; } void *ptr = operator new(AllocMemory_size); return ptr; } $ powerpc64le-linux-gnu-g++-13 -c Unified_cpp_gfx_skia17.ii -fno-exceptions -fno-strict-aliasing -fPIC -O2 during RTL pass: final Unified_cpp_gfx_skia17.ii: In function ‘void inlineStatement()’: Unified_cpp_gfx_skia17.ii:17:1: internal compiler error: output_operand: '%&' used without any local dynamic TLS references 17 | } | ^ 0xa06ff3 output_operand_lossage(char const*, ...) ../../src/gcc/final.cc:3190 0xa07373 output_operand(rtx_def*, int) ../../src/gcc/final.cc:3632 0xa07c5c output_asm_insn(char const*, rtx_def**) ../../src/gcc/final.cc:3557 0xa09517 final_scan_insn_1 ../../src/gcc/final.cc:2841 0xa09a08 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ../../src/gcc/final.cc:2887 0xa09c95 final_1 ../../src/gcc/final.cc:1979 0xa0a4a6 rest_of_handle_final ../../src/gcc/final.cc:4240 0xa0a4a6 execute ../../src/gcc/final.cc:4318 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. Configured with: ../src/configure -v --with-pkgversion='Debian 13.1.0-6' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --without-target-system-zlib --with-libphobos-druntime-only=yes --enable-secureplt --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-offload-targets=nvptx-none=/build/gcc-13-cross-pG4N37/gcc-13-cross-6/gcc/debian/tmp-nvptx/usr --enable-offload-defaulted --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=powerpc64le-linux-gnu --program-prefix=powerpc64le-linux-gnu- --includedir=/usr/powerpc64le-linux-gnu/include --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org @ 2023-07-10 6:42 ` rguenth at gcc dot gnu.org 2023-07-19 9:14 ` marcus at mc dot pp.se ` (9 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2023-07-10 6:42 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2023-07-10 Known to fail| |7.5.0 Ever confirmed|0 |1 Summary|[10/11/12/13/14] ICE |ICE output_operand: '%&' |output_operand: '%&' used |used without any local |without any local dynamic |dynamic TLS references on |TLS references on |powerpc64le-linux-gnu |powerpc64le-linux-gnu | --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- Unlikely that this is a regression. GCC 7 is also broken. But confirmed (with GCC 7). ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org 2023-07-10 6:42 ` [Bug target/110606] " rguenth at gcc dot gnu.org @ 2023-07-19 9:14 ` marcus at mc dot pp.se 2023-11-17 3:54 ` bergner at gcc dot gnu.org ` (8 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: marcus at mc dot pp.se @ 2023-07-19 9:14 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 marcus at mc dot pp.se changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus at mc dot pp.se --- Comment #2 from marcus at mc dot pp.se --- Happens also on big endian. (gcc 12.3.1) ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org 2023-07-10 6:42 ` [Bug target/110606] " rguenth at gcc dot gnu.org 2023-07-19 9:14 ` marcus at mc dot pp.se @ 2023-11-17 3:54 ` bergner at gcc dot gnu.org 2023-11-28 15:32 ` segher at gcc dot gnu.org ` (7 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: bergner at gcc dot gnu.org @ 2023-11-17 3:54 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 Peter Bergner <bergner at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bergner at gcc dot gnu.org, | |dje at gcc dot gnu.org, | |jeevitha at gcc dot gnu.org, | |linkw at gcc dot gnu.org, | |segher at gcc dot gnu.org --- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> --- I've asked Jeevitha to have a look at this one. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (2 preceding siblings ...) 2023-11-17 3:54 ` bergner at gcc dot gnu.org @ 2023-11-28 15:32 ` segher at gcc dot gnu.org 2023-11-28 15:43 ` segher at gcc dot gnu.org ` (6 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: segher at gcc dot gnu.org @ 2023-11-28 15:32 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> --- It needs -O2 -fPIC -fno-exceptions to fail. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (3 preceding siblings ...) 2023-11-28 15:32 ` segher at gcc dot gnu.org @ 2023-11-28 15:43 ` segher at gcc dot gnu.org 2023-12-04 9:36 ` jeevitha at gcc dot gnu.org ` (5 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: segher at gcc dot gnu.org @ 2023-11-28 15:43 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> --- The insn that it fails on is the result from a split using *tls_ld<bits> . ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (4 preceding siblings ...) 2023-11-28 15:43 ` segher at gcc dot gnu.org @ 2023-12-04 9:36 ` jeevitha at gcc dot gnu.org 2023-12-05 16:21 ` jeevitha at gcc dot gnu.org ` (4 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: jeevitha at gcc dot gnu.org @ 2023-12-04 9:36 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #6 from Jeevitha <jeevitha at gcc dot gnu.org> --- The ICE is happenning on the following insn at final_scan, (insn 80 146 111 (set (reg:DI 28 28 [145]) (high:DI (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) "test.ii":28:7 737 {*tls_ld_high64} (expr_list:REG_EQUIV (high:DI (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD)) (nil))) It was unable to parse the operand "%&" in the following instruction for above RTL. "addis %0,%1,%&@got@tlsld@ha" For the operand "%&" tries to retrive some local-dynamic symbol in that function but it return null. This happened because that function lost its symbol(it was dead insn and removed from split3). Unfortunately the reference are not removed, those instruction are unused but not eliminated which results in error. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (5 preceding siblings ...) 2023-12-04 9:36 ` jeevitha at gcc dot gnu.org @ 2023-12-05 16:21 ` jeevitha at gcc dot gnu.org 2023-12-05 17:26 ` segher at gcc dot gnu.org ` (3 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: jeevitha at gcc dot gnu.org @ 2023-12-05 16:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #7 from Jeevitha <jeevitha at gcc dot gnu.org> --- The following insns are dead at sched2, but not removed until pass_final, If these instruction are removed there will be no ICE. (insn 80 110 111 3 (set (reg:DI 28 28 [145]) (high:DI (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) "test.cc":27:7 737 {*tls_ld_high64} (expr_list:REG_EQUIV (high:DI (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD)) (nil))) (insn:TI 81 106 54 3 (set (reg:DI 28 28 [139]) (lo_sum:DI (reg:DI 28 28 [145]) (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) "test.cc":27:7 738 {*tls_ld_low64} (expr_list:REG_DEAD (reg:DI 2 2) (nil))) (insn 72 23 53 4 (set (reg:DI 3 3) (reg:DI 28 28 [139])) "test.cc":27:7 683 {*movdi_internal64} (nil)) call_insn/u 26 53 35 4 (parallel [ (set (reg:DI 3 3) (call (mem:SI (symbol_ref:DI ("__tls_get_addr") [flags 0x41] <function_decl 0x7ffff576df00 __tls_get_addr>) [0 S4 A8]) (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) (use (const_int 0 [0])) (clobber (reg:DI 96 lr)) ]) "test.cc":27:7 776 {*call_value_nonlocal_aixdi} (expr_list:REG_UNUSED (reg:DI 3 3) (expr_list:REG_CALL_DECL (symbol_ref:DI ("__tls_get_addr") [flags 0x41] <function_decl 0x7ffff576df00 __tls_get_addr>) (expr_list:REG_EH_REGION (const_int -2147483648 [0xffffffff80000000]) (nil)))) (expr_list (use (reg:DI 2 2)) (expr_list (use (reg:DI 3 3)) (nil)))) ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (6 preceding siblings ...) 2023-12-05 16:21 ` jeevitha at gcc dot gnu.org @ 2023-12-05 17:26 ` segher at gcc dot gnu.org 2023-12-05 18:26 ` jeevitha at gcc dot gnu.org ` (2 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: segher at gcc dot gnu.org @ 2023-12-05 17:26 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> --- What does "dead at sched2" mean? Are they dead when sched2 starts, or made dead by it? Well it must be the former; what pass does make it dead, then? split3 apparently? Why is this not done in split2 already, any good reason? ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (7 preceding siblings ...) 2023-12-05 17:26 ` segher at gcc dot gnu.org @ 2023-12-05 18:26 ` jeevitha at gcc dot gnu.org 2023-12-11 4:57 ` jeevitha at gcc dot gnu.org 2023-12-14 7:45 ` jeevitha at gcc dot gnu.org 10 siblings, 0 replies; 12+ messages in thread From: jeevitha at gcc dot gnu.org @ 2023-12-05 18:26 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #9 from Jeevitha <jeevitha at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #8) > What does "dead at sched2" mean? Are they dead when sched2 starts, or made > dead > by it? Well it must be the former; what pass does make it dead, then? > split3 > apparently? Why is this not done in split2 already, any good reason? Its latter, dead after sched2, DCE was happened in sched2 which removes the uses of reg 3, The following is the insn removed in sched2, (insn 28 26 29 4 (set (reg:DI 9 9 [132]) (unspec:DI [ (reg:DI 3 3 [142]) (symbol_ref:DI ("_ZL8sMemPool") [flags 0x1a] <var_decl 0x7ffff54d0ab0 sMemPool>) ] UNSPEC_TLSDTPRELHA)) "test.cc":27:7 740 {tls_dtprel_ha_64} (expr_list:REG_DEAD (reg:DI 3 3 [142]) (nil))) This makes the following insn unused, There was nouse of register 3 after this. call_insn/u 26 53 35 4 (parallel [ (set (reg:DI 3 3) (call (mem:SI (symbol_ref:DI ("__tls_get_addr") [flags 0x41] <function_decl 0x7ffff576df00 __tls_get_addr>) [0 S4 A8]) (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) (use (const_int 0 [0])) (clobber (reg:DI 96 lr)) ]) "test.cc":27:7 776 {*call_value_nonlocal_aixdi} ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (8 preceding siblings ...) 2023-12-05 18:26 ` jeevitha at gcc dot gnu.org @ 2023-12-11 4:57 ` jeevitha at gcc dot gnu.org 2023-12-14 7:45 ` jeevitha at gcc dot gnu.org 10 siblings, 0 replies; 12+ messages in thread From: jeevitha at gcc dot gnu.org @ 2023-12-11 4:57 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #10 from Jeevitha <jeevitha at gcc dot gnu.org> --- The following instructions [in basic block 4] were removed in sched2 DCE, which makes r3 unused [populated in call_insn 26], but they were not deleted in this pass itself: (insn 28 26 29 4 (set (reg:DI 9 9 [132]) (unspec:DI [ (reg:DI 3 3 [142]) (symbol_ref:DI ("_ZL8sMemPool") [flags 0x1a] <var_decl 0x7ffff54d0ab0 sMemPool>) ] UNSPEC_TLSDTPRELHA)) "test.cc":27:7 740 {tls_dtprel_ha_64} (expr_list:REG_DEAD (reg:DI 3 3 [142]) (nil))) (insn 29 28 35 4 (set (reg:DI 9 9 [130]) (unspec:DI [ (reg:DI 9 9 [132]) (symbol_ref:DI ("_ZL8sMemPool") [flags 0x1a] <var_decl 0x7ffff54d0ab0 sMemPool>) ] UNSPEC_TLSDTPRELLO)) "test.cc":27:7 741 {tls_dtprel_lo_64} (nil)) (insn 31 35 32 4 (set (reg/f:DI 9 9 [orig:133 sMemPool ] [133]) (mem/f/c:DI (reg:DI 9 9 [130]) [1 sMemPool+0 S8 A64])) "test.cc":27:3 683 {*movdi_internal64} (nil)) (insn 32 31 44 4 (set (reg:CC 100 0 [134]) (compare:CC (reg/f:DI 9 9 [orig:133 sMemPool ] [133]) (const_int 0 [0]))) "test.cc":27:3 799 {*cmpdi_signed} (expr_list:REG_DEAD (reg/f:DI 9 9 [orig:133 sMemPool ] [133]) (nil))) The following are the instructions that were not removed in sched2 DCE because they are avoiding call deletion [call_insn 26] with this flag [df_in_progress]. (insn 72 23 53 4 (set (reg:DI 3 3) (reg:DI 28 28 [139])) "test.cc":27:7 683 {*movdi_internal64} (nil)) (call_insn/u 26 53 35 4 (parallel [ (set (reg:DI 3 3) (call (mem:SI (symbol_ref:DI ("__tls_get_addr") [flags 0x41] <function_decl 0x7ffff576df00 __tls_get_addr>) [0 S4 A8]) (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) (use (const_int 0 [0])) (clobber (reg:DI 96 lr)) ]) "test.cc":27:7 776 {*call_value_nonlocal_aixdi} (expr_list:REG_UNUSED (reg:DI 3 3) (expr_list:REG_CALL_DECL (symbol_ref:DI ("__tls_get_addr") [flags 0x41] <function_decl 0x7ffff576df00 __tls_get_addr>) (expr_list:REG_EH_REGION (const_int -2147483648 [0xffffffff80000000]) (nil)))) (expr_list (use (reg:DI 2 2)) (expr_list (use (reg:DI 3 3)) (nil)))) Here, call_insn 26 becomes dead after deleting insn 28, but it is not removed. If call_insn 26 is removed, insn 72 can be removed. If insn 72 is removed, the following insns in basic block 3 can also be removed: (insn 80 136 81 3 (set (reg:DI 28 28 [145]) (high:DI (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) "test.cc":27:7 737 {*tls_ld_high64} (expr_list:REG_EQUIV (high:DI (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD)) (nil))) (insn 81 80 54 3 (set (reg:DI 28 28 [139]) (lo_sum:DI (reg:DI 28 28 [145]) (unspec:DI [ (reg:DI 2 2) ] UNSPEC_TLSLD))) "test.cc":27:7 738 {*tls_ld_low64} (expr_list:REG_DEAD (reg:DI 2 2) (nil))) Currently, we are encountering an ICE in insn 80 and 81. These two instructions are dead but remain unremoved until the final pass. They are attempting to retrieve a symbol that was present in insn 28, yet this insn has already been removed in sched2. When allowing sched2 to process call deletion, it successfully removed call_insn/u 26 and insn 72 in bb4, but not insn 80 and 81 because live registers are not updated for bb3 in same pass. It requires another DCE, but our GCC does not have DCE after sched2. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org ` (9 preceding siblings ...) 2023-12-11 4:57 ` jeevitha at gcc dot gnu.org @ 2023-12-14 7:45 ` jeevitha at gcc dot gnu.org 10 siblings, 0 replies; 12+ messages in thread From: jeevitha at gcc dot gnu.org @ 2023-12-14 7:45 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606 --- Comment #11 from Jeevitha <jeevitha at gcc dot gnu.org> --- Regarding the test case provided by Matthias Klose: Within the AllocMemory() routine, the compiler aimed to eliminate the entire if block but faced difficulties in removing references to the variable 'sMemPool'. The corresponding source code is as follows: if (sMemPool) { __trans_tmp_2 = operator new(AllocMemory_size); return __trans_tmp_2; } void *ptr = operator new(AllocMemory_size); return ptr; The subsequent details are pertaining to the body of if statement [BB5], which includes a 'mov' [insn 35] for "AllocMemory_size" and a 'call' [insn 36] for "operator new." Furthermore, regarding the code after the if body [BB6], there was another 'mov' [insn 43] and 'call' [insn 44], similar to those in BB5. Before SCHED1: -------------- BB5: insn 35 set r3, r124 insn 36 call [`operator new`] -> Uses r3,r2 ... insn 78 jump L47 L41: BB6: insn 43 set r3, r124 insn 44 call [`operator new`] -> Uses r3,r2 ... L47: BB7: insn 49 set r5, 0 insn 50 set r4, 1 During the 'sched1' pass, a reordering occurred that moved insn 35 before insn 31 from BB5 to BB4. BB4 contains the check for the 'sMempool' variable [insn 33]: if it's zero, there's a branch to label 41, leading to BB6; otherwise, it continues with BB5. After SCHED1: ------------- BB3: insn 80 set r145, high(unspec[r2]) insn 81 set r139, r145+low(unspec[r2])' BB4: insn 72 set r3, r139 insn 23 set r124, [r138] insn 26 call [`__tls_get_addr`] -> Uses r3,r2 insn 75 set r142, r3 insn 28 set r132, unspec[r142, symbol_ref: `_ZL8sMemPool`] insn 29 set r130, unspec[r132, symbol_ref: `_ZL8sMemPool`] insn 35 set r3, r124 insn 31 set r133, [r130] insn 32 set r134, cmp(r133, 0) insn 33 set pc, { (r134 == 0) ? L41 : pc } BB5: insn 36 call [`operator new`] -> Uses r3,r2 ... insn 78 jump L47 L41: BB6 insn 43 set r3, r124 insn 44 call [`operator new`] -> Uses r3,r2 ... L47: BB7: insn 49 set r5, 0 insn 50 set r4, 1 In the 'Jump2' pass, the compiler successfully removed the if body (bb5) consisting of insn 36 and insn 78. However, it couldn't remove insn 35, which was moved to bb4. Additionally, it changed insn 43 to be in bb6 and moved the remaining instructions from insn 44 to bb10. As insn 43 and insn 35 are similar instructions, insn 43 was chosen for deletion in the later pass. After JUMP2: ----------- BB3: .... insn 80 set r28[orig:r145], high(unspec[r2]) insn 81 set r28[orig:r139], r28[orig:r145]+low(unspec[r2])' .... BB4: .... .... insn 32 set cr0[orig:r134], cmp(r9[orig:r133], 0) insn 33 set pc, { (cr0[orig:r134] == 0) ? L41 : pc } BB5: insn 134 set pc, L133 L41: BB6: insn 43 set r3, r30[orig:r124] L133: BB10: insn 44 call [`operator new`] -> Uses r3,r2 insn 49 set r5,0 insn 50 set r4, 1 .... In cprop_hardreg pass, insn 43 in BB6 is removed After cprop_hardreg: -------------------- BB3: .... insn 80 set r28, high(unspec[r2]) insn 81 set r139, r28+low(unspec[r2])' .... BB4: insn 72 set r3, r28[orig:r139] insn 23 set r30[orig:r124], r27[orig:r138] insn 26 call [`__tls_get_addr`] -> Uses r3,r2 insn 28 set r9[orig:r132], unspec[r3[orig:r142],symbol_ref: `_ZL8sMemPool'] insn 29 set r9[orig:r130], unspec[r9[orig:r132],symbol_ref: `_ZL8sMemPool'] insn 35 set r3, r30[orig:r124] insn 31 set r9[orig:r133], [r9][orig:r130] insn 32 set cr0[orig:r134], cmp(r9[orig:r133], 0) insn 33 set pc, { (cr0[orig:r134] == 0) ? L41 : pc } BB5: insn 134 set pc, L133 L41: BB6: L133: BB10: insn 44 call [`operator new`] -> Uses r3,r2 insn 49 set r5,0 insn 50 set r4, 1 .... Following the removal of insn 43 in the 'cprop_hardreg' pass, both insn 134 and 33 became unnecessary due to jumping to the same location, which was removed in the basic block reordering pass. After BBRO: ----------- BB3: ... insn 80 set r28, high(unspec[r2]) insn 81 set r28, r28+low(unspec[r2])' ... BB4: insn 72 set r3, r28 insn 23 set r30, r27 insn 26 call [`__tls_get_addr`] -> Uses r3,r2 insn 28 set r9, unspec[r3,`_ZL8sMemPool'] insn 29 set r9, unspec[r9,`_ZL8sMemPool'] insn 35 set r3, r30 insn 31 set r9, [r9] insn 32 set cr0, cmp(r9, 0) insn 44 call [`operator new`] -> Uses r3,r2 insn 49 set r5,0 insn 50 set r4, 1 ... Upon the removal of these jumps, instructions 32, 31, 29, and 28 in bb4 became dead, since r9, r3 were used for those jumps. During 'sched2 DCE,' those instructions in BB4 were removed, rendering r3 unused (which was populated in insn 26). However, its not deleted in this pass: After SCHED2: ------------ BB3: ... insn 80 set r28, high(unspec[r2]) insn 81 set r28, r28+low(unspec[r2])' ... BB4: insn 23 set r30, r27 insn 72 set r3, r28 insn 26 call [`__tls_get_addr`] -> Uses r3,r2 insn 35 set r3, r30 insn 44 call [`operator new`] -> Uses r3,r2 insn 49 set r5,0 insn 50 set r4, 1 ... ... The flag 'df_in_progress' is avoiding the call deletion in 'sched2 DCE'. If the insn 26 is removed, insn 72 can be removed. Consequently, below instructions in BB3 could be removed if insn 72 were removed, BB3: insn 80 set r28, high(unspec[r2]) insn 81 set r28, r28+low(unspec[r2]) Currently, we have an ICE in insn 80 and 81. Despite of being dead instructions, they remain unremoved until the final pass. The final pass attempts to retrieve a dynamic symbol for insn 80 by iterating over all instruction below, it was present in insn 28. However, insn 28 has already been removed in 'sched2.' Enabling 'sched2' to handle call deletion successfully removed call_insn 26 and insn 72 in BB4. However, insns 80 and 81 were not removed because live registers (specifically, r28, which is unused) weren't updated for BB3 in the same pass. Another 'DCE' pass is required, but our GCC does not have 'DCE' after the 'sched2' pass. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-12-14 7:45 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-07-09 15:07 [Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu doko at gcc dot gnu.org 2023-07-10 6:42 ` [Bug target/110606] " rguenth at gcc dot gnu.org 2023-07-19 9:14 ` marcus at mc dot pp.se 2023-11-17 3:54 ` bergner at gcc dot gnu.org 2023-11-28 15:32 ` segher at gcc dot gnu.org 2023-11-28 15:43 ` segher at gcc dot gnu.org 2023-12-04 9:36 ` jeevitha at gcc dot gnu.org 2023-12-05 16:21 ` jeevitha at gcc dot gnu.org 2023-12-05 17:26 ` segher at gcc dot gnu.org 2023-12-05 18:26 ` jeevitha at gcc dot gnu.org 2023-12-11 4:57 ` jeevitha at gcc dot gnu.org 2023-12-14 7:45 ` jeevitha at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).