[Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[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]

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

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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).

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[marcus at mc dot pp.se]

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)

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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.

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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.

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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> .

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[jeevitha at gcc dot gnu.org]

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.

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[jeevitha at gcc dot gnu.org]

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))))

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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?

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[jeevitha at gcc dot gnu.org]

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}

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[jeevitha at gcc dot gnu.org]

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.

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

[jeevitha at gcc dot gnu.org]

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.