================
@@ -30,9 +30,14 @@ class ArchitecturePPC64 : public Architecture {
void AdjustBreakpointAddress(const Symbol &func,
Address &addr) const override;
+ lldb::ByteOrder GetVectorElementOrder() const override;
+
private:
static std::unique_ptr<Architecture> Create(const ArchSpec &arch);
- ArchitecturePPC64() = default;
+ ArchitecturePPC64(lldb::ByteOrder vector_element_order)
----------------
dsandersllvm wrote:
It's not the only big-endian target but it is the only target I know of where
the order of vector elements doesn't match LLVM-IR's order. MIPS and ARM both
have big-endian modes but vectors are 0-element first in both endians whereas
big-endian PowerPC is highest-indexed element first. If I hadn't handled this
then we'd read/write their vectors in reversed element order every time we
tried to copy memory to/from an LLVM-IR value.
MIPS and ARM's vector layout has a different quirk on LLVM-IR/memory which is
that bitcast isn't a no-op, it's a shuffle (which bytes swaps depends on the
types involved). This is because it's defined as a store of the original type
followed by a load of the new type. I haven't implemented this yet because I
didn't need to support vector bitcast.
https://github.com/llvm/llvm-project/pull/155000
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
