[llvm] [LangRef] Try to formalize the definition of "odr" in LLVM IR. (PR #92619)

Eli Friedman via llvm-commits llvm-commits at lists.llvm.org
Mon May 20 12:59:05 PDT 2024


https://github.com/efriedma-quic updated https://github.com/llvm/llvm-project/pull/92619

>From d9c00d44181aa43027ab8b3dc090ea04df059026 Mon Sep 17 00:00:00 2001
From: Eli Friedman <efriedma at quicinc.com>
Date: Fri, 17 May 2024 16:18:00 -0700
Subject: [PATCH 1/2] [LangRef] Try to formalize the definition of "odr" in
 LLVM IR.

The current definition is a bit fuzzy... replace it with something
that's somewhat rigorous.

For functions, the definition is pretty narrow; as a consequence of
language-level non-determinism, it's impossible to actually whether two
functions are equivalent, so just embrace the non-determinism.  For
constants, we're pretty strict; otherwise you end up concluding
constants can actually change value, which is bad for alias analysis.
I think C++ standard don't allow any non-deterministic operations in
constants, so we should be okay there?  Poison is per-byte to allow some
ambiguity in the way padding is defined.
---
 llvm/docs/LangRef.rst | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index e2f4d8bfcaeed..d503f060b3d04 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -290,13 +290,17 @@ linkage:
     symbol is weak until linked, if not linked, the symbol becomes null
     instead of being an undefined reference.
 ``linkonce_odr``, ``weak_odr``
-    Some languages allow differing globals to be merged, such as two
-    functions with different semantics. Other languages, such as
-    ``C++``, ensure that only equivalent globals are ever merged (the
-    "one definition rule" --- "ODR"). Such languages can use the
-    ``linkonce_odr`` and ``weak_odr`` linkage types to indicate that the
-    global will only be merged with equivalent globals. These linkage
-    types are otherwise the same as their non-``odr`` versions.
+    The ``odr`` suffix indicates that all globals defined with the given name
+    are equivalent, along the lines of the C++ "one definition rule" ("ODR").
+    Informally, this means we can inline functions and fold loads of constants.
+
+    Formally, use the following definition: when an ``odr`` function is
+    called, one of the definitions is non-deterministically chosen to run. For
+    ``odr`` variables, if the value any byte is not equal in all initializers,
+    that byte is a :ref:`poison value <poisonvalues>`. For aliases and ifuncs,
+    apply the rule for the underlying function or variable.
+
+    These linkage types are otherwise the same as their non-``odr`` versions.
 ``external``
     If none of the above identifiers are used, the global is externally
     visible, meaning that it participates in linkage and can be used to

>From c0717d9c58cb545ace8da4ee565c1e7add0734d3 Mon Sep 17 00:00:00 2001
From: Eli Friedman <efriedma at quicinc.com>
Date: Mon, 20 May 2024 12:58:57 -0700
Subject: [PATCH 2/2] Address review comments

---
 llvm/docs/LangRef.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index d503f060b3d04..358eb4b867925 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -296,9 +296,9 @@ linkage:
 
     Formally, use the following definition: when an ``odr`` function is
     called, one of the definitions is non-deterministically chosen to run. For
-    ``odr`` variables, if the value any byte is not equal in all initializers,
-    that byte is a :ref:`poison value <poisonvalues>`. For aliases and ifuncs,
-    apply the rule for the underlying function or variable.
+    ``odr`` variables, if any byte in the value is not equal in all
+    initializers, that byte is a :ref:`poison value <poisonvalues>`. For
+    aliases and ifuncs, apply the rule for the underlying function or variable.
 
     These linkage types are otherwise the same as their non-``odr`` versions.
 ``external``



More information about the llvm-commits mailing list