oskarwirga wrote:
> I changed my design, so I don't need this patch. Given
> https://godbolt.org/z/4KfEKq7zb, I can revert your patch, or just leave it as
> is. I have no preference.
I would prefer leaving it as is, I will make a note to revisit this pending
further testing on my end to see
https://github.com/oskarwirga requested changes to this pull request.
If you are going to remove this feature, I would rather you simply revert the
old commit. There is no point leaving the flag in at this point.
I had explored earlier dealing with the optimization at a later time in the
oskarwirga wrote:
> It happens later, in LLVM backend, it needs to be fixed.
>From https://github.com/llvm/llvm-project/pull/65972#issuecomment-1971855638
Is this something you have planned to fix? If not would replacing the .size()
counter with perhaps a seeded random uint8 be acceptable?
oskarwirga wrote:
> @oskarwirga I'd like to use this feature but without counter, preserving
> ubsan IDs
>
> Also I think in the current the counter has limited use: in optimized code,
> after inlining, it will have a lot of same ids, like 0, 1 from different
> functions.
>
> So I propose
@@ -688,6 +689,68 @@ void AArch64FrameLowering::emitCalleeSavedSVERestores(
emitCalleeSavedRestores(MBB, MBBI, true);
}
+void AArch64FrameLowering::allocateSVEStackSpace(
+MachineBasicBlock , MachineBasicBlock::iterator MBBI,
+StackOffset AllocSize, StackOffset
https://github.com/oskarwirga edited
https://github.com/llvm/llvm-project/pull/66524
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -688,6 +689,68 @@ void AArch64FrameLowering::emitCalleeSavedSVERestores(
emitCalleeSavedRestores(MBB, MBBI, true);
}
+void AArch64FrameLowering::allocateSVEStackSpace(
+MachineBasicBlock , MachineBasicBlock::iterator MBBI,
+StackOffset AllocSize, StackOffset
https://github.com/oskarwirga approved this pull request.
Testing this patch set on a complex application (including later PRs) yielded
no issues :)
Thank you for your work on this, I appreciate it!
https://github.com/llvm/llvm-project/pull/66524
@@ -9460,6 +9461,94 @@ bool AArch64InstrInfo::isReallyTriviallyReMaterializable(
return TargetInstrInfo::isReallyTriviallyReMaterializable(MI);
}
+MachineBasicBlock::iterator
+AArch64InstrInfo::insertStackProbingLoop(MachineBasicBlock::iterator MBBI,
+
oskarwirga wrote:
Apologies for still not being able to create a reproducible example I can share
but what I am seeing is the stack probe write overwriting the value at the tip
of the stack when I step debug execution:
```
str xzr, [sp, #-0x10 {var_70}]! {0x0}
...
sturx8, [x29,
oskarwirga wrote:
> Upon function entry the caller guarantees that it has probed the stack (e.g.
> performed a store) at some address [sp, #N], where0 <= N <= 1024.
I haven't been able to produce a minimal, sharable example as of yet, but I'm
encountering a runtime error associated with an
oskarwirga wrote:
I was able to confirm this stack works as expected in my local testing. I
haven't uncovered any further interactions with other mitigations. Thank you
for working on this!
https://github.com/llvm/llvm-project/pull/67123
___
https://github.com/oskarwirga approved this pull request.
https://github.com/llvm/llvm-project/pull/67123
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/oskarwirga commented:
I've reviewed the admittedly limited sections I'm familiar with and LGTM! This
is great work :)
https://github.com/llvm/llvm-project/pull/68750
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
oskarwirga wrote:
@vitalybuka Thank you for reviewing! Can you merge this? I don't have write
access (yet!)
https://github.com/llvm/llvm-project/pull/65972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/oskarwirga resolved
https://github.com/llvm/llvm-project/pull/65972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/oskarwirga updated
https://github.com/llvm/llvm-project/pull/65972
>From 8dd1d0c534faadd65f546a150bbd2cc5a132aa1e Mon Sep 17 00:00:00 2001
From: Oskar Wirga <10386631+oskarwi...@users.noreply.github.com>
Date: Wed, 27 Sep 2023 10:37:49 -0700
Subject: [PATCH 1/2] Modify
@@ -0,0 +1,83 @@
+; RUN: llc -O3 -mtriple arm64-linux -filetype asm -o - %s | FileCheck %s
-check-prefix CHECK-ASM
+; What this test does is check that even with nomerge, the functions still get
merged in
+; compiled code as the ubsantrap call gets lowered to a single
https://github.com/oskarwirga edited
https://github.com/llvm/llvm-project/pull/65972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
oskarwirga wrote:
CC: @vitalybuka I addressed some but not all comments pending further
clarification :)
https://github.com/llvm/llvm-project/pull/65972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/oskarwirga review_requested
https://github.com/llvm/llvm-project/pull/65972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/oskarwirga review_requested
https://github.com/llvm/llvm-project/pull/65972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/oskarwirga review_requested
https://github.com/llvm/llvm-project/pull/65972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/oskarwirga created
https://github.com/llvm/llvm-project/pull/65972:
Context
BoundsSanitizer is a mitigation that is part of UBSAN. It can be enabled in
"trap" mode to crash on OOB array accesses.
Problem
BoundsSan has zero false positives meaning every crash is a OOB array
24 matches
Mail list logo
