diff options
author | Björn Pettersson <bjorn.a.pettersson@ericsson.com> | 2023-10-16 14:53:53 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-10-16 14:53:53 +0200 |
commit | 4acb96c99f3b9c414f403f6e1ab2b317851abf0f (patch) | |
tree | b3d87be337017ad9fc6ee23d831e136a5e13fc87 /llvm/docs/LangRef.rst | |
parent | c202a17d024068c70364116f2d06535d79535b30 (diff) | |
download | llvm-4acb96c99f3b9c414f403f6e1ab2b317851abf0f.zip llvm-4acb96c99f3b9c414f403f6e1ab2b317851abf0f.tar.gz llvm-4acb96c99f3b9c414f403f6e1ab2b317851abf0f.tar.bz2 |
[SelectionDAG] Tidy up around endianness and isConstantSplat (#68212)
The BuildVectorSDNode::isConstantSplat function could depend on
endianness, and it takes a bool argument that can be used to indicate
if big or little endian should be considered when internally casting
from a vector to a scalar. However, that argument is default set to
false (= little endian). And in many situations, even in target
generic code such as DAGCombiner, the endianness isn't specified when
using the function.
The intent with this patch is to highlight that endianness doesn't
matter, depending on the context in which the function is used.
In DAGCombiner the code is slightly refactored. Back in the days when
the code was written it wasn't possible to request a MinSplatBits
size when calling isConstantSplat. Instead the code re-expanded the
found SplatValue to match with the EltBitWidth. Now we can just
provide EltBitWidth as MinSplatBits and remove the logic for doing
the re-expand.
While being at it, tidying up around isConstantSplat, this patch also
adds an explicit check in BuildVectorSDNode::isConstantSplat to break
out from the loop if trying to split an on VecWidth into two halves.
Haven't been able to prove that there could be miscompiles involved
if not doing so. There are lit tests that trigger that scenario,
although I think they happen to later discard the returned SplatValue
for other reasons.
Diffstat (limited to 'llvm/docs/LangRef.rst')
-rw-r--r-- | llvm/docs/LangRef.rst | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 3512347..ee893d8 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -3888,7 +3888,7 @@ integer to memory. A bitcast from a vector type to a scalar integer type will see the elements being packed together (without padding). The order in which elements are -inserted in the integer depends on endianess. For little endian element zero +inserted in the integer depends on endianness. For little endian element zero is put in the least significant bits of the integer, and for big endian element zero is put in the most significant bits. @@ -11677,7 +11677,7 @@ To convert pointers to other types, use the :ref:`inttoptr <i_inttoptr>` or :ref:`ptrtoint <i_ptrtoint>` instructions first. There is a caveat for bitcasts involving vector types in relation to -endianess. For example ``bitcast <2 x i8> <value> to i16`` puts element zero +endianness. For example ``bitcast <2 x i8> <value> to i16`` puts element zero of the vector in the least significant bits of the i16 for little-endian while element zero ends up in the most significant bits for big-endian. @@ -11686,9 +11686,9 @@ Example: .. code-block:: text - %X = bitcast i8 255 to i8 ; yields i8 :-1 - %Y = bitcast i32* %x to i16* ; yields i16*:%x - %Z = bitcast <2 x i32> %V to i64; ; yields i64: %V (depends on endianess) + %X = bitcast i8 255 to i8 ; yields i8 :-1 + %Y = bitcast i32* %x to i16* ; yields i16*:%x + %Z = bitcast <2 x i32> %V to i64; ; yields i64: %V (depends on endianness) %Z = bitcast <2 x i32*> %V to <2 x i64*> ; yields <2 x i64*> .. _i_addrspacecast: |