[llvm-branch-commits] [llvm] 56e2df9 - Fix warning when building with GCC.
Author: Owen Anderson
Date: 2023-01-09T21:17:51-07:00
New Revision: 56e2df99b1afacd7002ab594948784a1c4adf1d0
URL:
https://github.com/llvm/llvm-project/commit/56e2df99b1afacd7002ab594948784a1c4adf1d0
DIFF:
https://github.com/llvm/llvm-project/commit/56e2df99b1afacd7002ab594948784a1c4adf1d0.diff
LOG: Fix warning when building with GCC.
Added:
Modified:
llvm/lib/Support/CrashRecoveryContext.cpp
Removed:
diff --git a/llvm/lib/Support/CrashRecoveryContext.cpp
b/llvm/lib/Support/CrashRecoveryContext.cpp
index 9e792d1f5177..6b31a93a945f 100644
--- a/llvm/lib/Support/CrashRecoveryContext.cpp
+++ b/llvm/lib/Support/CrashRecoveryContext.cpp
@@ -20,7 +20,7 @@ using namespace llvm;
namespace {
struct CrashRecoveryContextImpl;
-LLVM_THREAD_LOCAL static const CrashRecoveryContextImpl *CurrentContext;
+static LLVM_THREAD_LOCAL const CrashRecoveryContextImpl *CurrentContext;
struct CrashRecoveryContextImpl {
// When threads are disabled, this links up all active
@@ -87,7 +87,7 @@ std::mutex &getCrashRecoveryContextMutex() {
static bool gCrashRecoveryEnabled = false;
-LLVM_THREAD_LOCAL static const CrashRecoveryContext *IsRecoveringFromCrash;
+static LLVM_THREAD_LOCAL const CrashRecoveryContext *IsRecoveringFromCrash;
} // namespace
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
@@ -660,42 +660,136 @@ Non-Integral Pointer Type Note: non-integral pointer types are a work in progress, and they should be considered experimental at this time. -LLVM IR optionally allows the frontend to denote pointers in certain address -spaces as "non-integral" via the :ref:`datalayout string`. -Non-integral pointer types represent pointers that have an *unspecified* bitwise -representation; that is, the integral representation may be target dependent or -unstable (not backed by a fixed integer). +For most targets, the pointer representation is a direct mapping from the +bitwise representation to the address of the underlying memory allocation. +Such pointers are considered "integral", and any pointers where the +representation is not just an integer address are called "non-integral". + +Non-integral pointers have at least one of the following three properties: + +* the pointer representation contains non-address bits +* the pointer representation is unstable (may changed at any time in a + target-specific way) +* the pointer representation has external state + +These properties (or combinations thereof) can be applied to pointers via the +:ref:`datalayout string`. + +The exact implications of these properties are target-specific. The following +subsections describe the IR semantics and restrictions to optimization passes +for each of these properties. + +Pointers with non-address bits +^^ + +Pointers in this address space have a bitwise representation that not only +has address bits, but also some other target-specific metadata. +In most cases pointers with a non-address bits behave exactly the same as an +integral pointer, the only difference is that it is not possible to create a +pointer just from an address unless all the non-address bits are also recreated +correctly in a target-specific way. +Since the address width such a pointer is not equal to the bitwise +representation, extracting the address will need to truncate to the index width +of the pointer. + +An example of pointers with non-address bits are the AMDGPU buffer descriptors +which are 160 bits: a 128-bit fat pointer and a 32-bit offset. +Similarly, CHERI capabilities contain a 32 or 64 bit address as well as the +same number of metadata bits, but unlike the AMDGPU buffer descriptors they have +external state in addition to non-address bits. + + +Unstable pointer representation +^^^ + +Pointers in this address space have an *unspecified* bitwise representation +(i.e. not backed by a fixed integer). The bitwise pattern of such pointers is +allowed to change in a target-specific way. For example, this could be a pointer +type used with copying garbage collection where the garbage collector could +update the pointer at any time in the collection sweep. ``inttoptr`` and ``ptrtoint`` instructions have the same semantics as for integral (i.e., normal) pointers in that they convert integers to and from -corresponding pointer types, but there are additional implications to be -aware of. Because the bit-representation of a non-integral pointer may -not be stable, two identical casts of the same operand may or may not +corresponding pointer types, but there are additional implications to be aware +of. + +For "unstable" pointer representations, the bit-representation of the pointer +may not be stable, so two identical casts of the same operand may or may not return the same value. Said differently, the conversion to or from the -non-integral type depends on environmental state in an implementation +"unstable" pointer type depends on environmental state in an implementation defined manner. - resistor wrote: Probably want to keep the paragraph break? https://github.com/llvm/llvm-project/pull/105735 ___ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
@@ -355,30 +364,111 @@ class DataLayout {
/// \sa DataLayout::getAddressSizeInBits
unsigned getAddressSize(unsigned AS) const { return getIndexSize(AS); }
- /// Return the address spaces containing non-integral pointers. Pointers in
- /// this address space don't have a well-defined bitwise representation.
- SmallVector getNonIntegralAddressSpaces() const {
+ /// Return the address spaces with special pointer semantics (such as being
+ /// unstable or non-integral).
+ SmallVector getNonStandardAddressSpaces() const {
SmallVector AddrSpaces;
for (const PointerSpec &PS : PointerSpecs) {
- if (PS.IsNonIntegral)
+ if (PS.HasUnstableRepresentation || PS.HasExternalState ||
+ PS.BitWidth != PS.IndexBitWidth)
AddrSpaces.push_back(PS.AddrSpace);
}
return AddrSpaces;
}
+ /// Returns whether this address space has a non-integral pointer
+ /// representation, i.e. the pointer is not just an integer address but some
+ /// other bitwise representation. When true, passes cannot assume that all
+ /// bits of the representation map directly to the allocation address.
+ /// NOTE: This also returns true for "unstable" pointers where the
+ /// representation may be just an address, but this value can change at any
+ /// given time (e.g. due to copying garbage collection).
+ /// Examples include AMDGPU buffer descriptors with a 128-bit fat pointer
+ /// and a 32-bit offset or CHERI capabilities that contain bounds,
permissions
+ /// and an out-of-band validity bit.
+ ///
+ /// In general, more specialized functions such as shouldAvoidIntToPtr(),
+ /// shouldAvoidPtrToInt(), or hasExternalState() should be preferred over
+ /// this one when reasoning about the behavior of IR analysis/transforms.
+ /// TODO: should remove/deprecate this once all uses have migrated.
bool isNonIntegralAddressSpace(unsigned AddrSpace) const {
-return getPointerSpec(AddrSpace).IsNonIntegral;
+const auto &PS = getPointerSpec(AddrSpace);
+return PS.BitWidth != PS.IndexBitWidth || PS.HasUnstableRepresentation ||
+ PS.HasExternalState;
+ }
+
+ /// Returns whether this address space has an "unstable" pointer
+ /// representation. The bitwise pattern of such pointers is allowed to change
+ /// in a target-specific way. For example, this could be used for copying
+ /// garbage collection where the garbage collector could update the pointer
+ /// value as part of the collection sweep.
+ bool hasUnstableRepresentation(unsigned AddrSpace) const {
+return getPointerSpec(AddrSpace).HasUnstableRepresentation;
+ }
+ bool hasUnstableRepresentation(Type *Ty) const {
+auto *PTy = dyn_cast(Ty->getScalarType());
+return PTy && hasUnstableRepresentation(PTy->getPointerAddressSpace());
+ }
+
+ /// Returns whether this address space has external state (implies having
+ /// a non-integral pointer representation).
+ /// These pointer types must be loaded and stored using appropriate
+ /// instructions and cannot use integer loads/stores as this would not
+ /// propagate the out-of-band state. An example of such a pointer type is a
+ /// CHERI capability that contain bounds, permissions and an out-of-band
+ /// validity bit that is invalidated whenever an integer/FP store is
performed
+ /// to the associated memory location.
+ bool hasExternalState(unsigned AddrSpace) const {
+return getPointerSpec(AddrSpace).HasExternalState;
+ }
+ bool hasExternalState(Type *Ty) const {
+auto *PTy = dyn_cast(Ty->getScalarType());
+return PTy && hasExternalState(PTy->getPointerAddressSpace());
+ }
+
+ /// Returns whether passes should avoid introducing `inttoptr` instructions
+ /// for this address space.
+ ///
+ /// This is currently the case for non-integral pointer representations with
+ /// external state (hasExternalState()) since `inttoptr` cannot recreate the
+ /// external state bits.
+ /// New `inttoptr` instructions should also be avoided for "unstable" bitwise
+ /// representations (hasUnstableRepresentation()) unless the pass knows it is
+ /// within a critical section that retains the current representation.
+ bool shouldAvoidIntToPtr(unsigned AddrSpace) const {
+return hasUnstableRepresentation(AddrSpace) || hasExternalState(AddrSpace);
+ }
+
+ /// Returns whether passes should avoid introducing `ptrtoint` instructions
+ /// for this address space.
+ ///
+ /// This is currently the case for pointer address spaces that have an
+ /// "unstable" representation (hasUnstableRepresentation()) since the
+ /// bitwise pattern of such pointers could change unless the pass knows it is
+ /// within a critical section that retains the current representation.
+ bool shouldAvoidPtrToInt(unsigned AddrSpace) const {
resistor wrote:
Same
https://github.com/llvm/llvm-project/pull/105735
___
llvm-branch-commits mailing list
llvm-branch-co
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
@@ -660,42 +660,136 @@ Non-Integral Pointer Type Note: non-integral pointer types are a work in progress, and they should be considered experimental at this time. -LLVM IR optionally allows the frontend to denote pointers in certain address -spaces as "non-integral" via the :ref:`datalayout string`. -Non-integral pointer types represent pointers that have an *unspecified* bitwise -representation; that is, the integral representation may be target dependent or -unstable (not backed by a fixed integer). +For most targets, the pointer representation is a direct mapping from the +bitwise representation to the address of the underlying memory allocation. +Such pointers are considered "integral", and any pointers where the +representation is not just an integer address are called "non-integral". + +Non-integral pointers have at least one of the following three properties: + +* the pointer representation contains non-address bits +* the pointer representation is unstable (may changed at any time in a + target-specific way) +* the pointer representation has external state + +These properties (or combinations thereof) can be applied to pointers via the +:ref:`datalayout string`. + +The exact implications of these properties are target-specific. The following +subsections describe the IR semantics and restrictions to optimization passes +for each of these properties. + +Pointers with non-address bits +^^ + +Pointers in this address space have a bitwise representation that not only +has address bits, but also some other target-specific metadata. +In most cases pointers with a non-address bits behave exactly the same as an +integral pointer, the only difference is that it is not possible to create a resistor wrote: s/an integral pointer/integral pointers/ https://github.com/llvm/llvm-project/pull/105735 ___ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
@@ -660,42 +660,136 @@ Non-Integral Pointer Type Note: non-integral pointer types are a work in progress, and they should be considered experimental at this time. -LLVM IR optionally allows the frontend to denote pointers in certain address -spaces as "non-integral" via the :ref:`datalayout string`. -Non-integral pointer types represent pointers that have an *unspecified* bitwise -representation; that is, the integral representation may be target dependent or -unstable (not backed by a fixed integer). +For most targets, the pointer representation is a direct mapping from the +bitwise representation to the address of the underlying memory allocation. +Such pointers are considered "integral", and any pointers where the +representation is not just an integer address are called "non-integral". + +Non-integral pointers have at least one of the following three properties: + +* the pointer representation contains non-address bits +* the pointer representation is unstable (may changed at any time in a + target-specific way) +* the pointer representation has external state + +These properties (or combinations thereof) can be applied to pointers via the +:ref:`datalayout string`. + +The exact implications of these properties are target-specific. The following +subsections describe the IR semantics and restrictions to optimization passes +for each of these properties. + +Pointers with non-address bits +^^ + +Pointers in this address space have a bitwise representation that not only +has address bits, but also some other target-specific metadata. +In most cases pointers with a non-address bits behave exactly the same as an resistor wrote: s/with a non-address bits/with non-address bits/ https://github.com/llvm/llvm-project/pull/105735 ___ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
https://github.com/resistor edited https://github.com/llvm/llvm-project/pull/105735 ___ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
@@ -355,30 +364,111 @@ class DataLayout {
/// \sa DataLayout::getAddressSizeInBits
unsigned getAddressSize(unsigned AS) const { return getIndexSize(AS); }
- /// Return the address spaces containing non-integral pointers. Pointers in
- /// this address space don't have a well-defined bitwise representation.
- SmallVector getNonIntegralAddressSpaces() const {
+ /// Return the address spaces with special pointer semantics (such as being
+ /// unstable or non-integral).
+ SmallVector getNonStandardAddressSpaces() const {
SmallVector AddrSpaces;
for (const PointerSpec &PS : PointerSpecs) {
- if (PS.IsNonIntegral)
+ if (PS.HasUnstableRepresentation || PS.HasExternalState ||
+ PS.BitWidth != PS.IndexBitWidth)
AddrSpaces.push_back(PS.AddrSpace);
}
return AddrSpaces;
}
+ /// Returns whether this address space has a non-integral pointer
+ /// representation, i.e. the pointer is not just an integer address but some
+ /// other bitwise representation. When true, passes cannot assume that all
+ /// bits of the representation map directly to the allocation address.
+ /// NOTE: This also returns true for "unstable" pointers where the
+ /// representation may be just an address, but this value can change at any
+ /// given time (e.g. due to copying garbage collection).
+ /// Examples include AMDGPU buffer descriptors with a 128-bit fat pointer
+ /// and a 32-bit offset or CHERI capabilities that contain bounds,
permissions
+ /// and an out-of-band validity bit.
+ ///
+ /// In general, more specialized functions such as shouldAvoidIntToPtr(),
+ /// shouldAvoidPtrToInt(), or hasExternalState() should be preferred over
+ /// this one when reasoning about the behavior of IR analysis/transforms.
+ /// TODO: should remove/deprecate this once all uses have migrated.
bool isNonIntegralAddressSpace(unsigned AddrSpace) const {
-return getPointerSpec(AddrSpace).IsNonIntegral;
+const auto &PS = getPointerSpec(AddrSpace);
+return PS.BitWidth != PS.IndexBitWidth || PS.HasUnstableRepresentation ||
+ PS.HasExternalState;
+ }
+
+ /// Returns whether this address space has an "unstable" pointer
+ /// representation. The bitwise pattern of such pointers is allowed to change
+ /// in a target-specific way. For example, this could be used for copying
+ /// garbage collection where the garbage collector could update the pointer
+ /// value as part of the collection sweep.
+ bool hasUnstableRepresentation(unsigned AddrSpace) const {
+return getPointerSpec(AddrSpace).HasUnstableRepresentation;
+ }
+ bool hasUnstableRepresentation(Type *Ty) const {
+auto *PTy = dyn_cast(Ty->getScalarType());
+return PTy && hasUnstableRepresentation(PTy->getPointerAddressSpace());
+ }
+
+ /// Returns whether this address space has external state (implies having
+ /// a non-integral pointer representation).
+ /// These pointer types must be loaded and stored using appropriate
+ /// instructions and cannot use integer loads/stores as this would not
+ /// propagate the out-of-band state. An example of such a pointer type is a
+ /// CHERI capability that contain bounds, permissions and an out-of-band
+ /// validity bit that is invalidated whenever an integer/FP store is
performed
+ /// to the associated memory location.
+ bool hasExternalState(unsigned AddrSpace) const {
+return getPointerSpec(AddrSpace).HasExternalState;
+ }
+ bool hasExternalState(Type *Ty) const {
+auto *PTy = dyn_cast(Ty->getScalarType());
+return PTy && hasExternalState(PTy->getPointerAddressSpace());
+ }
+
+ /// Returns whether passes should avoid introducing `inttoptr` instructions
+ /// for this address space.
+ ///
+ /// This is currently the case for non-integral pointer representations with
+ /// external state (hasExternalState()) since `inttoptr` cannot recreate the
+ /// external state bits.
+ /// New `inttoptr` instructions should also be avoided for "unstable" bitwise
+ /// representations (hasUnstableRepresentation()) unless the pass knows it is
+ /// within a critical section that retains the current representation.
+ bool shouldAvoidIntToPtr(unsigned AddrSpace) const {
resistor wrote:
I hate nit-picking names, but the phrasing of this hook makes it sound like a
performance hint rather than a semantic requirement.
https://github.com/llvm/llvm-project/pull/105735
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
https://github.com/resistor commented: Line edits and naming https://github.com/llvm/llvm-project/pull/105735 ___ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
@@ -660,42 +660,136 @@ Non-Integral Pointer Type Note: non-integral pointer types are a work in progress, and they should be considered experimental at this time. -LLVM IR optionally allows the frontend to denote pointers in certain address -spaces as "non-integral" via the :ref:`datalayout string`. -Non-integral pointer types represent pointers that have an *unspecified* bitwise -representation; that is, the integral representation may be target dependent or -unstable (not backed by a fixed integer). +For most targets, the pointer representation is a direct mapping from the +bitwise representation to the address of the underlying memory allocation. +Such pointers are considered "integral", and any pointers where the +representation is not just an integer address are called "non-integral". + +Non-integral pointers have at least one of the following three properties: + +* the pointer representation contains non-address bits +* the pointer representation is unstable (may changed at any time in a + target-specific way) +* the pointer representation has external state + +These properties (or combinations thereof) can be applied to pointers via the +:ref:`datalayout string`. + +The exact implications of these properties are target-specific. The following +subsections describe the IR semantics and restrictions to optimization passes +for each of these properties. + +Pointers with non-address bits +^^ + +Pointers in this address space have a bitwise representation that not only +has address bits, but also some other target-specific metadata. +In most cases pointers with a non-address bits behave exactly the same as an +integral pointer, the only difference is that it is not possible to create a +pointer just from an address unless all the non-address bits are also recreated +correctly in a target-specific way. +Since the address width such a pointer is not equal to the bitwise resistor wrote: s/address width such/address width of such/ https://github.com/llvm/llvm-project/pull/105735 ___ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)
@@ -355,30 +364,111 @@ class DataLayout {
/// \sa DataLayout::getAddressSizeInBits
unsigned getAddressSize(unsigned AS) const { return getIndexSize(AS); }
- /// Return the address spaces containing non-integral pointers. Pointers in
- /// this address space don't have a well-defined bitwise representation.
- SmallVector getNonIntegralAddressSpaces() const {
+ /// Return the address spaces with special pointer semantics (such as being
+ /// unstable or non-integral).
+ SmallVector getNonStandardAddressSpaces() const {
SmallVector AddrSpaces;
for (const PointerSpec &PS : PointerSpecs) {
- if (PS.IsNonIntegral)
+ if (PS.HasUnstableRepresentation || PS.HasExternalState ||
+ PS.BitWidth != PS.IndexBitWidth)
AddrSpaces.push_back(PS.AddrSpace);
}
return AddrSpaces;
}
+ /// Returns whether this address space has a non-integral pointer
+ /// representation, i.e. the pointer is not just an integer address but some
+ /// other bitwise representation. When true, passes cannot assume that all
+ /// bits of the representation map directly to the allocation address.
+ /// NOTE: This also returns true for "unstable" pointers where the
+ /// representation may be just an address, but this value can change at any
+ /// given time (e.g. due to copying garbage collection).
+ /// Examples include AMDGPU buffer descriptors with a 128-bit fat pointer
+ /// and a 32-bit offset or CHERI capabilities that contain bounds,
permissions
+ /// and an out-of-band validity bit.
+ ///
+ /// In general, more specialized functions such as shouldAvoidIntToPtr(),
+ /// shouldAvoidPtrToInt(), or hasExternalState() should be preferred over
+ /// this one when reasoning about the behavior of IR analysis/transforms.
+ /// TODO: should remove/deprecate this once all uses have migrated.
bool isNonIntegralAddressSpace(unsigned AddrSpace) const {
-return getPointerSpec(AddrSpace).IsNonIntegral;
+const auto &PS = getPointerSpec(AddrSpace);
+return PS.BitWidth != PS.IndexBitWidth || PS.HasUnstableRepresentation ||
+ PS.HasExternalState;
+ }
+
+ /// Returns whether this address space has an "unstable" pointer
+ /// representation. The bitwise pattern of such pointers is allowed to change
+ /// in a target-specific way. For example, this could be used for copying
+ /// garbage collection where the garbage collector could update the pointer
+ /// value as part of the collection sweep.
+ bool hasUnstableRepresentation(unsigned AddrSpace) const {
+return getPointerSpec(AddrSpace).HasUnstableRepresentation;
+ }
+ bool hasUnstableRepresentation(Type *Ty) const {
+auto *PTy = dyn_cast(Ty->getScalarType());
+return PTy && hasUnstableRepresentation(PTy->getPointerAddressSpace());
+ }
+
+ /// Returns whether this address space has external state (implies having
+ /// a non-integral pointer representation).
+ /// These pointer types must be loaded and stored using appropriate
+ /// instructions and cannot use integer loads/stores as this would not
+ /// propagate the out-of-band state. An example of such a pointer type is a
+ /// CHERI capability that contain bounds, permissions and an out-of-band
+ /// validity bit that is invalidated whenever an integer/FP store is
performed
+ /// to the associated memory location.
+ bool hasExternalState(unsigned AddrSpace) const {
+return getPointerSpec(AddrSpace).HasExternalState;
+ }
+ bool hasExternalState(Type *Ty) const {
+auto *PTy = dyn_cast(Ty->getScalarType());
+return PTy && hasExternalState(PTy->getPointerAddressSpace());
+ }
+
+ /// Returns whether passes should avoid introducing `inttoptr` instructions
+ /// for this address space.
+ ///
+ /// This is currently the case for non-integral pointer representations with
+ /// external state (hasExternalState()) since `inttoptr` cannot recreate the
+ /// external state bits.
+ /// New `inttoptr` instructions should also be avoided for "unstable" bitwise
+ /// representations (hasUnstableRepresentation()) unless the pass knows it is
+ /// within a critical section that retains the current representation.
+ bool shouldAvoidIntToPtr(unsigned AddrSpace) const {
resistor wrote:
I'm not strongly opinionated on whether it should exist or not, but if it's
going to exist I would name it something more forceful like
`mustNotIntroduceIntToPtr`
https://github.com/llvm/llvm-project/pull/105735
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
