[Bug target/100354] New: [9 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[Bug target/100354] New: [9 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

            Bug ID: 100354
           Summary: [9 regression] aarch64: non-deligitimized UNSPEC
                    UNSPEC_TLS (76) found in variable location
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

i see this note/warning a lot during an aarch64 glibc build
since gcc-9, it seems to require -O -g, and seems to be
harmless wrt code generation, just annoying.

$ cat bug.c
struct s {
  void *p;
  int n;
};

void foo(struct s *x)
{
  void *p = __builtin_thread_pointer();
  if (x->p != p)
    x->p = p;
  x->n++;
}

$ aarch64-none-linux-gnu-gcc -S -O1 -g bug.c
bug.c: In function ‘foo’:
bug.c:6:6: note: non-delegitimized UNSPEC UNSPEC_TLS (76) found in variable
location
    6 | void foo(struct s *x)
      |      ^~~


may be related to bug 89006

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64
      Known to fail|                            |10.3.0, 11.1.0, 12.0, 9.3.0
            Summary|[9 regression] aarch64:     |[9/10/11/12 regression]
                   |non-deligitimized UNSPEC    |aarch64: non-deligitimized
                   |UNSPEC_TLS (76) found in    |UNSPEC UNSPEC_TLS (76)
                   |variable location           |found in variable location
                 CC|                            |acoplan at gcc dot gnu.org
   Last reconfirmed|                            |2021-04-30
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Confirmed.

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.4

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ardb at kernel dot org

--- Comment #3 from Alex Coplan <acoplan at gcc dot gnu.org> ---
*** Bug 102914 has been marked as a duplicate of this bug. ***

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2021-04-30 00:00:00         |2022-1-21
           Priority|P3                          |P2
                 CC|                            |jakub at gcc dot gnu.org
           Keywords|                            |diagnostic

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is dwarf2out.cc

      /* If delegitimize_address couldn't do anything with the UNSPEC, and
         the target hook doesn't explicitly allow it in debug info, assume
         we can't express it in the debug info.  */
      /* Don't complain about TLS UNSPECs, those are just too hard to
         delegitimize.  Note this could be a non-decl SYMBOL_REF such as
         one in a constant pool entry, so testing SYMBOL_REF_TLS_MODEL
         rather than DECL_THREAD_LOCAL_P is not just an optimization.  */
      if (flag_checking
          && (XVECLEN (rtl, 0) == 0
              || GET_CODE (XVECEXP (rtl, 0, 0)) != SYMBOL_REF
              || SYMBOL_REF_TLS_MODEL (XVECEXP (rtl, 0, 0)) == TLS_MODEL_NONE))
        inform (current_function_decl
                ? DECL_SOURCE_LOCATION (current_function_decl)
                : UNKNOWN_LOCATION,
#if NUM_UNSPEC_VALUES > 0
                "non-delegitimized UNSPEC %s (%d) found in variable location",
                ((XINT (rtl, 1) >= 0 && XINT (rtl, 1) < NUM_UNSPEC_VALUES)
                 ? unspec_strings[XINT (rtl, 1)] : "unknown"),
#else
                "non-delegitimized UNSPEC %d found in variable location",
#endif
                XINT (rtl, 1));

btw, the following expansion_failed () will just dump to a dumpfile,
maybe the above inform was meant to do the same.

Jakub, you added this in g:eb1fcdaa11c571780374065c383708826624f22d - it's
guarded with -fchecking but I think this is the only place in GCC I know
we have actual debug diagnostics this way.

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is a note to backend maintainers that they should try harder if possible to
delegitimize it.

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In this particular case it is:
(note 38 19 20 (var_location p (unspec:DI [
        (const_int 0 [0])
    ] UNSPEC_TLS)) NOTE_INSN_VAR_LOCATION)
where p's value should be equal to that __builtin_thread_pointer () aka the
base of the TLS region.

I wonder if it could be represented as DW_OP_lit0 DW_OP_form_tls_address,
one would need to test that in debugger.
And if it works, figure out some target independent way or perhaps a target
hook that would propagate this case from the target dependent UNSPEC_TLS to
dwarf2out.cc that it could emit such location.

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktkachov at gcc dot gnu.org,
                   |                            |rearnsha at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It could be e.g. done by having the targetm.const_not_ok_for_debug_p target
hook not return true for the UNSPEC_TLS case and have some new target hook that
would handle emitting debug info for an UNSPEC.

Or a way to just quiet the note (I'll repeat it is -fchecking only) would be to
use as the operand of UNSPEC_TLS not const0_rtx as it does, but some magic
SYMBOL_REF with SYMBOL_REF_TLS_MODEL non-zero on it.  Say like:
--- gcc/config/aarch64/aarch64.md.jj    2022-01-11 23:11:21.682300103 +0100
+++ gcc/config/aarch64/aarch64.md       2022-02-08 19:51:00.581676457 +0100
@@ -6833,7 +6833,8 @@ (define_insn "ldr_got_tiny_sidi"

 (define_insn "aarch64_load_tp_hard"
   [(set (match_operand:DI 0 "register_operand" "=r")
-       (unspec:DI [(const_int 0)] UNSPEC_TLS))]
+       (unspec:DI [(match_operand 1 "aarch64_tls_le_symref" "S")]
+                  UNSPEC_TLS))]
   ""
   "mrs\\t%0, tpidr_el0"
   [(set_attr "type" "mrs")]
--- gcc/config/aarch64/aarch64.cc.jj    2022-02-04 14:36:54.262615676 +0100
+++ gcc/config/aarch64/aarch64.cc       2022-02-08 19:46:58.206051731 +0100
@@ -18474,7 +18474,9 @@ aarch64_load_tp (rtx target)
     target = gen_reg_rtx (Pmode);

   /* Can return in any reg.  */
-  emit_insn (gen_aarch64_load_tp_hard (target));
+  rtx sym = gen_rtx_SYMBOL_REF (Pmode, "");
+  SYMBOL_REF_FLAGS (sym) = TLS_MODEL_LOCAL_EXEC << SYMBOL_FLAG_TLS_SHIFT;
+  emit_insn (gen_aarch64_load_tp_hard (target, sym));
   return target;
 }

[Bug target/100354] [10/11/12/13 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug target/100354] [10/11/12/13 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug target/100354] [11/12/13/14 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug target/100354] [11/12/13 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13/14 regression]    |[11/12/13 regression]
                   |aarch64: non-deligitimized  |aarch64: non-deligitimized
                   |UNSPEC UNSPEC_TLS (76)      |UNSPEC UNSPEC_TLS (76)
                   |found in variable location  |found in variable location
                 CC|                            |law at gcc dot gnu.org

--- Comment #11 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Seems to be working on the trunk.  Removing gcc-14 regression marker.

[Bug target/100354] [11/12/13/14 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13 regression]       |[11/12/13/14 regression]
                   |aarch64: non-deligitimized  |aarch64: non-deligitimized
                   |UNSPEC UNSPEC_TLS (76)      |UNSPEC UNSPEC_TLS (76)
                   |found in variable location  |found in variable location

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am still able to reproduce it on the trunk with `-g -O -fchecking` on
aarch64-linux-gnu built as of last night.

[Bug target/100354] [12/13/14/15 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.5                        |12.5

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11 branch is being closed.