@@ -1319,6 +1319,83 @@ shouldReportReturnGadget(const BinaryContext &BC, const
MCInstReference &Inst,
return make_gadget_report(RetKind, Inst, *RetReg);
}
+/// While BOLT already marks some of the branch instructions as tail calls,
+/// this function tries to improve the co
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/137224
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1751,6 +1750,25 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
Inst.addOperand(MCOperand::createImm(0));
}
+ bool isTrap(const MCInst &Inst) const override {
+if (Inst.getOpcode() != AArch64::BRK)
+ return false;
+// Only match the immediate val
https://github.com/kbeyls commented:
Thanks, mostly looks good, I only have 1 nitpicky comment about the underlying
reason why the pauth analyzer should have a slightly different "definition" of
what is considered a tail call versus BOLT overall.
https://github.com/llvm/llvm-project/pull/13722
https://github.com/kbeyls approved this pull request.
This looks like a great simple improvement, thanks!
https://github.com/llvm/llvm-project/pull/141824
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/141824
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/136151
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls approved this pull request.
https://github.com/llvm/llvm-project/pull/136151
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -985,6 +985,26 @@ inst_pacnbibsppc:
ret
.size inst_pacnbibsppc, .-inst_pacnbibsppc
+// Test that write-back forms of LDRA(A|B) instructions are handled properly.
+
+.globl inst_ldraa_wb
+.type inst_ldraa_wb,@function
+inst_ldraa_wb:
+// CH
kbeyls wrote:
Thanks, this mostly looks good to me.
I just left a few nit-picky questions or comments inline
https://github.com/llvm/llvm-project/pull/136147
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm
kbeyls wrote:
> @kbeyls Looks like something went wrong with the UI, and only the "cover
> letter" was sent instead of the full review.
Ah yes, my apologies... Hopefully you can see the inline comments now...
https://github.com/llvm/llvm-project/pull/136147
@@ -787,19 +794,20 @@ shouldReportSigningOracle(const BinaryContext &BC, const
MCInstReference &Inst,
const SrcState &S) {
static const GadgetKind SigningOracleKind("signing oracle found");
- MCPhysReg SignedReg = BC.MIB->getSignedReg(Inst);
- if
@@ -562,35 +562,55 @@ class MCPlusBuilder {
return {};
}
- virtual ErrorOr getAuthenticatedReg(const MCInst &Inst) const {
-llvm_unreachable("not implemented");
-return getNoRegister();
- }
-
- virtual bool isAuthenticationOfReg(const MCInst &Inst,
-
@@ -717,6 +716,466 @@ SrcSafetyAnalysis::create(BinaryFunction &BF,
RegsToTrackInstsFor);
}
+/// A state representing which registers are safe to be used as the destination
+/// operand of an authentication instruction.
+/
@@ -198,73 +198,147 @@ raw_ostream &operator<<(raw_ostream &OS, const
MCInstReference &);
namespace PAuthGadgetScanner {
+// The report classes are designed to be used in an immutable manner.
+// When an issue report is constructed in multiple steps, an attempt is made
+// t
https://github.com/kbeyls commented:
I just have a few more nit-picky comments/questions, but overall looks good to
me.
https://github.com/llvm/llvm-project/pull/135662
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://li
@@ -198,73 +198,147 @@ raw_ostream &operator<<(raw_ostream &OS, const
MCInstReference &);
namespace PAuthGadgetScanner {
+// The report classes are designed to be used in an immutable manner.
+// When an issue report is constructed in multiple steps, an attempt is made
+// t
@@ -720,16 +713,30 @@ SrcSafetyAnalysis::create(BinaryFunction &BF,
RegsToTrackInstsFor);
}
-static std::shared_ptr
+static BriefReport make_generic_report(MCInstReference Location,
+
@@ -198,73 +198,147 @@ raw_ostream &operator<<(raw_ostream &OS, const
MCInstReference &);
namespace PAuthGadgetScanner {
+// The report classes are designed to be used in an immutable manner.
+// When an issue report is constructed in multiple steps, an attempt is made
+// t
@@ -198,73 +198,147 @@ raw_ostream &operator<<(raw_ostream &OS, const
MCInstReference &);
namespace PAuthGadgetScanner {
+// The report classes are designed to be used in an immutable manner.
+// When an issue report is constructed in multiple steps, an attempt is made
+// t
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/135662
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -355,6 +389,46 @@ class SrcSafetyAnalysis {
return Regs;
}
+ // Returns all registers made trusted by this instruction.
+ SmallVector getRegsMadeTrusted(const MCInst &Point,
+const SrcState &Cur) const {
+SmallVector R
@@ -591,7 +591,9 @@ obscure_indirect_call_arg_nocfg:
.globl safe_lr_at_function_entry_nocfg
.type safe_lr_at_function_entry_nocfg,@function
safe_lr_at_function_entry_nocfg:
-// CHECK-NOT: safe_lr_at_function_entry_nocfg
+// Due to state being reset after a la
https://github.com/kbeyls approved this pull request.
Thanks for your patience with my many questions!
This looks good to merge to me now.
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.l
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -462,7 +563,22 @@ class DataflowSrcSafetyAnalysis
return DFParent::getStateBefore(Inst);
}
- void run() override { DFParent::run(); }
+ void run() override {
+for (BinaryBasicBlock &BB : Func) {
+ if (auto CheckerInfo = BC.MIB->getAuthCheckedReg(BB)) {
+
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/135661
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls approved this pull request.
https://github.com/llvm/llvm-project/pull/135661
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -462,7 +563,22 @@ class DataflowSrcSafetyAnalysis
return DFParent::getStateBefore(Inst);
}
- void run() override { DFParent::run(); }
+ void run() override {
+for (BinaryBasicBlock &BB : Func) {
+ if (auto CheckerInfo = BC.MIB->getAuthCheckedReg(BB)) {
+
https://github.com/kbeyls commented:
I finally managed to read through this patch end-to-end.
I only have 3 very nit-picky questions left.
This looks almost ready to merge.
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailin
@@ -355,6 +389,46 @@ class SrcSafetyAnalysis {
return Regs;
}
+ // Returns all registers made trusted by this instruction.
+ SmallVector getRegsMadeTrusted(const MCInst &Point,
+const SrcState &Cur) const {
+SmallVector R
@@ -591,7 +591,9 @@ obscure_indirect_call_arg_nocfg:
.globl safe_lr_at_function_entry_nocfg
.type safe_lr_at_function_entry_nocfg,@function
safe_lr_at_function_entry_nocfg:
-// CHECK-NOT: safe_lr_at_function_entry_nocfg
+// Due to state being reset after a la
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -339,6 +369,198 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
}
}
+ std::optional>
+ getAuthCheckedReg(BinaryBasicBlock &BB) const override {
+// Match several possible hard-coded sequences of instructions which can be
+// emitted by LLVM backend to
https://github.com/kbeyls commented:
Apologies for only reviewing piece-meal. I'm struggling a bit at the time to
reserve longer blocks of time to review this fully in one go.
I hope my comments still make sense though
https://github.com/llvm/llvm-project/pull/134146
___
@@ -339,6 +369,183 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
}
}
+ std::optional>
+ getAuthCheckedReg(BinaryBasicBlock &BB) const override {
+// Match several possible hard-coded sequences of instructions which can be
+// emitted by LLVM backend to
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -339,6 +369,183 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
}
}
+ std::optional>
+ getAuthCheckedReg(BinaryBasicBlock &BB) const override {
+// Match several possible hard-coded sequences of instructions which can be
+// emitted by LLVM backend to
https://github.com/kbeyls commented:
Just adding a few more comments as I'm reading through the patch.
I haven't yet managed to read the full patch in detail yet
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
@@ -339,6 +369,183 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
}
}
+ std::optional>
+ getAuthCheckedReg(BinaryBasicBlock &BB) const override {
+// Match several possible hard-coded sequences of instructions which can be
+// emitted by LLVM backend to
@@ -307,8 +340,10 @@ class SrcSafetyAnalysis {
SrcState createEntryState() {
SrcState S(NumRegs, RegsToTrackInstsFor.getNumTrackedRegisters());
-for (MCPhysReg Reg : BC.MIB->getTrustedLiveInRegs())
- S.SafeToDerefRegs |= BC.MIB->getAliases(Reg, /*OnlySmaller=*/t
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -622,6 +628,40 @@ class MCPlusBuilder {
return std::make_pair(getNoRegister(), getNoRegister());
}
+ /// Analyzes if a pointer is checked to be valid by the end of BB.
+ ///
+ /// It is possible for pointer authentication instructions not to terminate
+ /// the pr
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/135661
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/135661
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-com
@@ -622,6 +628,40 @@ class MCPlusBuilder {
return std::make_pair(getNoRegister(), getNoRegister());
}
+ /// Analyzes if a pointer is checked to be valid by the end of BB.
+ ///
+ /// It is possible for pointer authentication instructions not to terminate
+ /// the pr
https://github.com/kbeyls commented:
Thanks for the updates.
I managed to glance through the whole PR now.
I will do a more detailed review once my main currently remaining question is
answered about which cases are supported and which ones are not supported. I
think this should be written up a
https://github.com/kbeyls approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/133461
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-com
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/133461
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -622,6 +628,40 @@ class MCPlusBuilder {
return std::make_pair(getNoRegister(), getNoRegister());
}
+ /// Analyzes if a pointer is checked to be valid by the end of BB.
+ ///
+ /// It is possible for pointer authentication instructions not to terminate
+ /// the pr
@@ -622,6 +628,40 @@ class MCPlusBuilder {
return std::make_pair(getNoRegister(), getNoRegister());
}
+ /// Analyzes if a pointer is checked to be valid by the end of BB.
+ ///
+ /// It is possible for pointer authentication instructions not to terminate
+ /// the pr
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/134146
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls commented:
I only reviewed a small part of this PR so far, but will probably not have more
time today or tomorrow to review further, so I thought I'd share my thoughts so
far.
I think that the documentation at
https://github.com/llvm/llvm-project/blob/main/bolt/docs/
@@ -622,6 +628,40 @@ class MCPlusBuilder {
return std::make_pair(getNoRegister(), getNoRegister());
}
+ /// Analyzes if a pointer is checked to be valid by the end of BB.
kbeyls wrote:
"a pointer being valid" could mean many things in this target-agnos
@@ -622,6 +628,40 @@ class MCPlusBuilder {
return std::make_pair(getNoRegister(), getNoRegister());
}
+ /// Analyzes if a pointer is checked to be valid by the end of BB.
+ ///
+ /// It is possible for pointer authentication instructions not to terminate
+ /// the pr
@@ -0,0 +1,7343 @@
+/*
+ * xxHash - Extremely Fast Hash algorithm
+ * Header File
+ * Copyright (C) 2012-2023 Yann Collet
+ *
+ * BSD 2-Clause License (https://www.opensource.org/licenses/bsd-license.php)
kbeyls wrote:
This is a license different from Apache-2.0
@@ -304,6 +304,36 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
}
}
+ MCPhysReg getSafelyMaterializedAddressReg(const MCInst &Inst) const override
{
+switch (Inst.getOpcode()) {
+case AArch64::ADR:
+case AArch64::ADRP:
kbeyls wrote
@@ -587,6 +587,22 @@ class MCPlusBuilder {
return getNoRegister();
}
+ virtual MCPhysReg getSafelyMaterializedAddressReg(const MCInst &Inst) const {
+llvm_unreachable("not implemented");
+return getNoRegister();
+ }
kbeyls wrote:
Thanks, it's
@@ -355,37 +399,39 @@ class PacRetAnalysis
return State();
}
+// First, compute various properties of the instruction, taking the state
+// before its execution into account, if necessary.
+
+BitVector Clobbered = getClobberedRegs(Point);
+// Compute
@@ -587,6 +587,22 @@ class MCPlusBuilder {
return getNoRegister();
}
+ virtual MCPhysReg getSafelyMaterializedAddressReg(const MCInst &Inst) const {
+llvm_unreachable("not implemented");
+return getNoRegister();
+ }
+
+ /// Analyzes if this instruction can saf
@@ -1,7 +1,8 @@
if "AArch64" not in config.root.targets:
config.unsupported = True
-flags = "--target=aarch64-linux-gnu -nostartfiles -nostdlib -ffreestanding"
+# -Wl,--no-relax prevents converting ADRP+ADD pairs into NOP+ADR.
+flags = "--target=aarch64-linux-gnu -nostartf
@@ -335,6 +335,50 @@ class PacRetAnalysis
});
}
+ BitVector getClobberedRegs(const MCInst &Point) const {
+BitVector Clobbered(NumRegs, false);
+// Assume a call can clobber all registers, including callee-saved
+// registers. There's a good chance that call
@@ -587,6 +587,22 @@ class MCPlusBuilder {
return getNoRegister();
}
+ virtual MCPhysReg getSafelyMaterializedAddressReg(const MCInst &Inst) const {
+llvm_unreachable("not implemented");
+return getNoRegister();
+ }
kbeyls wrote:
I think that
@@ -0,0 +1,115 @@
+#include
kbeyls wrote:
This new file needs a license header, I guess?
https://github.com/llvm/llvm-project/pull/133530
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https:/
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/133308
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls approved this pull request.
https://github.com/llvm/llvm-project/pull/133308
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -577,6 +577,16 @@ class MCPlusBuilder {
return getNoRegister();
}
+ /// Returns the register used as call destination, or no-register, if not
+ /// an indirect call. Sets IsAuthenticatedInternally if the instruction
+ /// accepts signed pointer as its operand and a
@@ -0,0 +1,676 @@
+// RUN: %clang %cflags -march=armv8.3-a %s -o %t.exe
+// RUN: llvm-bolt-binary-analysis --scanners=pacret %t.exe 2>&1 | FileCheck %s
kbeyls wrote:
I'm wondering if the user interface for this should be adapted?
`pac-ret` is a widely deployed h
https://github.com/kbeyls edited
https://github.com/llvm/llvm-project/pull/131899
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kbeyls commented:
I haven't had time yet to review the test cases, but I thought I'd share my
comments so far already.
https://github.com/llvm/llvm-project/pull/131899
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.l
@@ -0,0 +1,676 @@
+// RUN: %clang %cflags -march=armv8.3-a %s -o %t.exe
+// RUN: llvm-bolt-binary-analysis --scanners=pacret %t.exe 2>&1 | FileCheck %s
+
+// FIXME In the below test cases, LR is usually not spilled as needed, as it is
+// not checked by BOLT.
---
@@ -382,11 +382,11 @@ class PacRetAnalysis
public:
std::vector
- getLastClobberingInsts(const MCInst Ret, BinaryFunction &BF,
- const ArrayRef UsedDirtyRegs) const {
kbeyls wrote:
I was wondering whether `const` has to be removed he
@@ -277,6 +277,48 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
}
}
+ MCPhysReg
+ getRegUsedAsCallDest(const MCInst &Inst,
+ bool &IsAuthenticatedInternally) const override {
kbeyls wrote:
I'm wondering if this could be
@@ -139,64 +262,59 @@ bool
SLSHardeningInserter::hardenReturnsAndBRs(MachineModuleInfo &MMI,
return Modified;
}
-static const unsigned NumPermittedRegs = 29;
-static const struct ThunkNameAndReg {
- const char* Name;
- Register Reg;
-} SLSBLRThunks[NumPermittedRegs] = {
-
@@ -221,13 +339,19 @@ void SLSHardeningInserter::populateThunk(MachineFunction
&MF) {
// __llvm_slsblr_thunk_xN:
// BR xN
// barrierInsts
kbeyls wrote:
As part of reviewing this, I was wondering why the actual thunk content is
```
// __llv
@@ -221,13 +339,19 @@ void SLSHardeningInserter::populateThunk(MachineFunction
&MF) {
// __llvm_slsblr_thunk_xN:
// BR xN
// barrierInsts
kbeyls wrote:
Maybe something like
```
// __llvm_slsblr_thunk_{aa|ab|aaz|abz|}_xN_{xM}:
// BR
@@ -68,6 +156,57 @@ struct SLSHardeningInserter :
ThunkInserter {
} // end anonymous namespace
+const ThunkKind ThunkKind::BR = {ThunkBR, "", false, false, AArch64::BR};
+const ThunkKind ThunkKind::BRAA = {ThunkBRAA, "aa_", true, true,
AArch64::BRAA};
+const ThunkKind Thunk
@@ -68,6 +156,57 @@ struct SLSHardeningInserter :
ThunkInserter {
} // end anonymous namespace
+const ThunkKind ThunkKind::BR = {ThunkBR, "", false, false, AArch64::BR};
+const ThunkKind ThunkKind::BRAA = {ThunkBRAA, "aa_", true, true,
AArch64::BRAA};
+const ThunkKind Thunk
@@ -221,13 +339,19 @@ void SLSHardeningInserter::populateThunk(MachineFunction
&MF) {
// __llvm_slsblr_thunk_xN:
// BR xN
// barrierInsts
kbeyls wrote:
I think it would be useful to update this comment to make it clear what the
different kin
@@ -0,0 +1,210 @@
+# RUN: llc -verify-machineinstrs -mtriple=aarch64-none-linux-gnu \
+# RUN: -start-before aarch64-sls-hardening -o - %s \
+# RUN: -asm-verbose=0 \
+# RUN: | FileCheck %s \
+# RUN: --implicit-check-not=__llvm_slsblr_thunk_aa_x5_x8 \
+# RUN: --impli
@@ -274,40 +398,31 @@ void SLSHardeningInserter::convertBLRToBL(
MachineInstr &BLR = *MBBI;
assert(isBLR(BLR));
- unsigned BLOpcode;
- Register Reg;
- bool RegIsKilled;
- switch (BLR.getOpcode()) {
- case AArch64::BLR:
- case AArch64::BLRNoIP:
-BLOpcode = AArch64
https://github.com/kbeyls commented:
Thank you, this mostly looks good to me.
I've only added very minor comments; feel free to disagree with them.
https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits
https://github.com/kbeyls edited https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -68,6 +156,57 @@ struct SLSHardeningInserter :
ThunkInserter {
} // end anonymous namespace
+const ThunkKind ThunkKind::BR = {ThunkBR, "", false, false, AArch64::BR};
+const ThunkKind ThunkKind::BRAA = {ThunkBRAA, "aa_", true, true,
AArch64::BRAA};
+const ThunkKind Thunk
@@ -36,38 +32,43 @@ using namespace llvm;
#define AARCH64_SLS_HARDENING_NAME "AArch64 sls hardening pass"
+static const char SLSBLRNamePrefix[] = "__llvm_slsblr_thunk_";
+
namespace {
-class AArch64SLSHardening : public MachineFunctionPass {
-public:
- const TargetInstrIn
@@ -36,38 +32,43 @@ using namespace llvm;
#define AARCH64_SLS_HARDENING_NAME "AArch64 sls hardening pass"
+static const char SLSBLRNamePrefix[] = "__llvm_slsblr_thunk_";
+
namespace {
-class AArch64SLSHardening : public MachineFunctionPass {
-public:
- const TargetInstrIn
@@ -46,13 +40,5 @@ body: |
...
-name:__llvm_slsblr_thunk_x8
-tracksRegLiveness: true
-body: |
- bb.0.entry:
-liveins: $x8
-BR $x8
kbeyls wrote:
I think it is important to check that the body of the thunk in
https://github.com/kbeyls approved this pull request.
https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
kbeyls wrote:
> [37c84b9](https://github.com/llvm/llvm-project/pull/94394/commits/37c84b9dce70f40db8a7c27b7de8232c4d10f78f)
> shows what I had in mind, let me know what you all think. I added:
>
> ```
> void getSipHash_2_4_64(ArrayRef In, const uint8_t (&K)[16],
>uint8_t
kbeyls wrote:
> Yes, this doesn't have tests by itself because there's no exposed interface.
> It's certainly trivial to add one (which would allow using the reference test
> vectors).
>
> I don't have strong arguments either way, but I figured the conservative
> option is to force hypothetic
https://github.com/kbeyls approved this pull request.
https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
kbeyls wrote:
I just checked if there indeed are big-endian bots which should pick up if a
different hash gets produced on a big-endian system. I guess this bot (the only
bot?) would pick it up: https://lab.llvm.org/buildbot/#/builders/231
I now also realize that there are no tests with this c
kbeyls wrote:
> So, regarding big-endian things. Original siphash is always "little-endian"
> regardless of the host platform. On big endian hosts it essentially does byte
> swap in the end. We do not have it here, so we will end with different hashes
> on platforms with different endianness.
kbeyls wrote:
> I'll also mention that I left the original variable naming but did re-format
> the file, whitespace being more friendly to diffs, and this being nice and
> tidily contained. If you or others have strong opinions, I'm happy to
> recapitalize the names.
I don't have a strong opi
@@ -1,25 +1,19 @@
-/*
- SipHash reference C implementation
-
- Copyright (c) 2012-2022 Jean-Philippe Aumasson
-
- Copyright (c) 2012-2014 Daniel J. Bernstein
-
- To the extent possible under law, the author(s) have dedicated all copyright
- and related and neighborin
@@ -58,21 +38,15 @@
v2 = ROTL(v2, 32);
\
} while (0)
-/*
-Computes a SipHash value
-*in: pointer to input data (read-only)
-inlen: input data length in bytes (any size_t value)
-*k: pointer to the k
https://github.com/kbeyls requested changes to this pull request.
Do I understand correctly that "remove big-endian support" results in this code
not running correctly on big-endian machines?
I don't recall the LLVM project claiming that it cannot run on big-endian
machines.
If I understand thi
@@ -58,21 +38,15 @@
v2 = ROTL(v2, 32);
\
} while (0)
-/*
kbeyls wrote:
It might be worthwhile to keep (an edited version of) this comment? It wasn't
immediately obvious to me what the value is of
@@ -58,21 +38,15 @@
v2 = ROTL(v2, 32);
\
} while (0)
-/*
-Computes a SipHash value
-*in: pointer to input data (read-only)
-inlen: input data length in bytes (any size_t value)
-*k: pointer to the k
1 - 100 of 109 matches
Mail list logo
