[asan] isInterestingAlloca: remove the isAllocaPromotable condition #77221

MaskRay · 2024-01-07T04:47:21Z

Commit 8ed1d81 made an AllocaInst
interesting only if
!ClSkipPromotableAllocas || !isAllocaPromotable(&AI), which greatly
removed memory operand instrumention for -O0. However, this optimization
is subsumed by StackSafetyAnalysis and therefore unnecessary when we
enable StackSafetyAnalysis by default. With this patch,
-fsanitize=address built clang does not change with -O0 or -O3.

Actually, having the !ClSkipPromotableAllocas || !isAllocaPromotable(&AI)
condition before !(SSGI && SSGI->isSafe(AI))) has an interesting false
positive involving MemIntrinsic (see hoist-argument-init-insts.ll):

isInterestingAlloca is transitively called by
getInterestingMemoryOperands and FunctionStackPoisoner.
If getInterestingMemoryOperands never calls
StackSafetyGlobalInfo::getInfo, and a MemIntrinsic is converted to
__asan_memcpy by instrumentMemIntrinsic, when
StackSafetyGlobalInfo::getInfo is called, StackSafetyAnalysis will
consider __asan_memcpy as unsafe, leading to an unnecessary
alloca instrumentation

Created using spr 1.3.4

llvmbot · 2024-01-07T04:47:49Z

@llvm/pr-subscribers-llvm-transforms

Author: Fangrui Song (MaskRay)

Changes

Commit 8ed1d81 made an AllocaInst
interesting only if
!ClSkipPromotableAllocas || !isAllocaPromotable(&AI), which greatly
removed memory operand instrumention for -O0. However, this optimization
is subsumed by StackSafetyAnalysis and therefore unnecessary when we
enable StackSafetyAnalysis by default.

Actually, having the !ClSkipPromotableAllocas || !isAllocaPromotable(&AI)
condition before !(SSGI && SSGI->isSafe(AI))) has an interesting false
positive involving MemIntrinsic (see hoist-argument-init-insts.ll):

isInterestingAlloca is transitively called by
getInterestingMemoryOperands and FunctionStackPoisoner.
If getInterestingMemoryOperands never calls
StackSafetyGlobalInfo::getInfo, and a MemIntrinsic is converted to
__asan_memcpy by instrumentMemIntrinsic, when
StackSafetyGlobalInfo::getInfo is called, StackSafetyAnalysis will
consider __asan_memcpy as unsafe, leading to an unnecessary
alloca instrumentation

Full diff: https://github.com/llvm/llvm-project/pull/77221.diff

4 Files Affected:

(modified) llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp (+1-9)
(modified) llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll (+3-3)
(modified) llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll (+3-2)
(modified) llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll (+1-1)

diff --git a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
index 5e7e08eaa9978d..4dfb85b70d77d6 100644
--- a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -345,11 +345,6 @@ static cl::opt<bool>
                                cl::desc("instrument dynamic allocas"),
                                cl::Hidden, cl::init(true));
 
-static cl::opt<bool> ClSkipPromotableAllocas(
-    "asan-skip-promotable-allocas",
-    cl::desc("Do not instrument promotable allocas"), cl::Hidden,
-    cl::init(true));
-
 static cl::opt<AsanCtorKind> ClConstructorKind(
     "asan-constructor-kind",
     cl::desc("Sets the ASan constructor kind"),
@@ -1278,9 +1273,6 @@ bool AddressSanitizer::isInterestingAlloca(const AllocaInst &AI) {
       (AI.getAllocatedType()->isSized() &&
        // alloca() may be called with 0 size, ignore it.
        ((!AI.isStaticAlloca()) || !getAllocaSizeInBytes(AI).isZero()) &&
-       // We are only interested in allocas not promotable to registers.
-       // Promotable allocas are common under -O0.
-       (!ClSkipPromotableAllocas || !isAllocaPromotable(&AI)) &&
        // inalloca allocas are not treated as static, and we don't want
        // dynamic alloca instrumentation for them as well.
        !AI.isUsedWithInAlloca() &&
@@ -1311,7 +1303,7 @@ bool AddressSanitizer::ignoreAccess(Instruction *Inst, Value *Ptr) {
   // will not cause memory violations. This greatly speeds up the instrumented
   // executable at -O0.
   if (auto AI = dyn_cast_or_null<AllocaInst>(Ptr))
-    if (ClSkipPromotableAllocas && !isInterestingAlloca(*AI))
+    if (!isInterestingAlloca(*AI))
       return true;
 
   if (SSGI != nullptr && SSGI->stackAccessIsSafe(*Inst) &&
diff --git a/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll b/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll
index 6237673921978f..1f1049d6f625ef 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll
@@ -10,19 +10,19 @@ target triple = "x86_64-apple-macosx10.10.0"
 
 define i32 @foo() sanitize_address {
 entry:
-  ; Won't be instrumented because of asan-skip-promotable-allocas.
+  ; Won't be instrumented because of asan-use-safety-analysis.
   %non_instrumented1 = alloca i32, align 4
 
   ; Regular alloca, will get instrumented (forced by the ptrtoint below).
   %instrumented = alloca i32, align 4
 
-  ; Won't be instrumented because of asan-skip-promotable-allocas.
+  ; Won't be instrumented because of asan-use-safety-analysis.
   %non_instrumented2 = alloca i32, align 4
 
   br label %bb0
 
 bb0:
-  ; Won't be instrumented because of asan-skip-promotable-allocas.
+  ; Won't be instrumented because of asan-use-safety-analysis.
   %non_instrumented3 = alloca i32, align 4
 
   %ptr = ptrtoint ptr %instrumented to i32
diff --git a/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll b/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll
index 5ecd4dc7fb9430..85bfe761aee6a9 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll
@@ -1,4 +1,4 @@
-; RUN: opt < %s -passes=asan -asan-use-after-scope -asan-use-stack-safety=1 -S | FileCheck %s
+; RUN: opt < %s -passes=asan -asan-use-after-scope -asan-use-stack-safety=1 -S | FileCheck %s --implicit-check-not=__asan_stack_malloc
 
 ; Source (-O0 -fsanitize=address -fsanitize-address-use-after-scope):
 ;; struct S { int x, y; };
@@ -21,13 +21,14 @@ target triple = "x86_64-apple-macosx10.14.0"
 ; CHECK:      %a.addr = alloca ptr, align 8
 ; CHECK-NEXT: %b.addr = alloca ptr, align 8
 ; CHECK-NEXT: %doit.addr = alloca i8, align 1
+; CHECK-NEXT: %tmp = alloca %struct.S, align 4
 
 ; Next, the stores into the argument allocas.
 ; CHECK-NEXT: store ptr {{.*}}, ptr %a.addr
 ; CHECK-NEXT: store ptr {{.*}}, ptr %b.addr
 ; CHECK-NEXT: [[frombool:%.*]] = zext i1 {{.*}} to i8
 ; CHECK-NEXT: store i8 %frombool, ptr %doit.addr, align 1
-; CHECK-NEXT: [[stack_base:%.*]] = alloca i64, align 8
+; CHECK-NOT:  alloca i64, align 8
 
 define void @_Z4swapP1SS0_b(ptr %a, ptr %b, i1 zeroext %doit) sanitize_address {
 entry:
diff --git a/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll b/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll
index 4e8466b685689b..8e30fc29382373 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll
@@ -1,4 +1,4 @@
-; RUN: opt -S -passes=asan -asan-use-stack-safety=0 -asan-skip-promotable-allocas=0 %s -o - | FileCheck %s
+; RUN: opt -S -passes=asan -asan-use-stack-safety=0 %s -o - | FileCheck %s
 ; Generated from:
 ; int bar(int y) {
 ;   return y + 2;

llvmbot · 2024-01-07T04:47:49Z

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Fangrui Song (MaskRay)

Changes

Commit 8ed1d81 made an AllocaInst
interesting only if
!ClSkipPromotableAllocas || !isAllocaPromotable(&AI), which greatly
removed memory operand instrumention for -O0. However, this optimization
is subsumed by StackSafetyAnalysis and therefore unnecessary when we
enable StackSafetyAnalysis by default.

Actually, having the !ClSkipPromotableAllocas || !isAllocaPromotable(&AI)
condition before !(SSGI && SSGI->isSafe(AI))) has an interesting false
positive involving MemIntrinsic (see hoist-argument-init-insts.ll):

isInterestingAlloca is transitively called by
getInterestingMemoryOperands and FunctionStackPoisoner.
If getInterestingMemoryOperands never calls
StackSafetyGlobalInfo::getInfo, and a MemIntrinsic is converted to
__asan_memcpy by instrumentMemIntrinsic, when
StackSafetyGlobalInfo::getInfo is called, StackSafetyAnalysis will
consider __asan_memcpy as unsafe, leading to an unnecessary
alloca instrumentation

Full diff: https://github.com/llvm/llvm-project/pull/77221.diff

4 Files Affected:

(modified) llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp (+1-9)
(modified) llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll (+3-3)
(modified) llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll (+3-2)
(modified) llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll (+1-1)

diff --git a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
index 5e7e08eaa9978d..4dfb85b70d77d6 100644
--- a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -345,11 +345,6 @@ static cl::opt<bool>
                                cl::desc("instrument dynamic allocas"),
                                cl::Hidden, cl::init(true));
 
-static cl::opt<bool> ClSkipPromotableAllocas(
-    "asan-skip-promotable-allocas",
-    cl::desc("Do not instrument promotable allocas"), cl::Hidden,
-    cl::init(true));
-
 static cl::opt<AsanCtorKind> ClConstructorKind(
     "asan-constructor-kind",
     cl::desc("Sets the ASan constructor kind"),
@@ -1278,9 +1273,6 @@ bool AddressSanitizer::isInterestingAlloca(const AllocaInst &AI) {
       (AI.getAllocatedType()->isSized() &&
        // alloca() may be called with 0 size, ignore it.
        ((!AI.isStaticAlloca()) || !getAllocaSizeInBytes(AI).isZero()) &&
-       // We are only interested in allocas not promotable to registers.
-       // Promotable allocas are common under -O0.
-       (!ClSkipPromotableAllocas || !isAllocaPromotable(&AI)) &&
        // inalloca allocas are not treated as static, and we don't want
        // dynamic alloca instrumentation for them as well.
        !AI.isUsedWithInAlloca() &&
@@ -1311,7 +1303,7 @@ bool AddressSanitizer::ignoreAccess(Instruction *Inst, Value *Ptr) {
   // will not cause memory violations. This greatly speeds up the instrumented
   // executable at -O0.
   if (auto AI = dyn_cast_or_null<AllocaInst>(Ptr))
-    if (ClSkipPromotableAllocas && !isInterestingAlloca(*AI))
+    if (!isInterestingAlloca(*AI))
       return true;
 
   if (SSGI != nullptr && SSGI->stackAccessIsSafe(*Inst) &&
diff --git a/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll b/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll
index 6237673921978f..1f1049d6f625ef 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/debug_info_noninstrumented_alloca.ll
@@ -10,19 +10,19 @@ target triple = "x86_64-apple-macosx10.10.0"
 
 define i32 @foo() sanitize_address {
 entry:
-  ; Won't be instrumented because of asan-skip-promotable-allocas.
+  ; Won't be instrumented because of asan-use-safety-analysis.
   %non_instrumented1 = alloca i32, align 4
 
   ; Regular alloca, will get instrumented (forced by the ptrtoint below).
   %instrumented = alloca i32, align 4
 
-  ; Won't be instrumented because of asan-skip-promotable-allocas.
+  ; Won't be instrumented because of asan-use-safety-analysis.
   %non_instrumented2 = alloca i32, align 4
 
   br label %bb0
 
 bb0:
-  ; Won't be instrumented because of asan-skip-promotable-allocas.
+  ; Won't be instrumented because of asan-use-safety-analysis.
   %non_instrumented3 = alloca i32, align 4
 
   %ptr = ptrtoint ptr %instrumented to i32
diff --git a/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll b/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll
index 5ecd4dc7fb9430..85bfe761aee6a9 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/hoist-argument-init-insts.ll
@@ -1,4 +1,4 @@
-; RUN: opt < %s -passes=asan -asan-use-after-scope -asan-use-stack-safety=1 -S | FileCheck %s
+; RUN: opt < %s -passes=asan -asan-use-after-scope -asan-use-stack-safety=1 -S | FileCheck %s --implicit-check-not=__asan_stack_malloc
 
 ; Source (-O0 -fsanitize=address -fsanitize-address-use-after-scope):
 ;; struct S { int x, y; };
@@ -21,13 +21,14 @@ target triple = "x86_64-apple-macosx10.14.0"
 ; CHECK:      %a.addr = alloca ptr, align 8
 ; CHECK-NEXT: %b.addr = alloca ptr, align 8
 ; CHECK-NEXT: %doit.addr = alloca i8, align 1
+; CHECK-NEXT: %tmp = alloca %struct.S, align 4
 
 ; Next, the stores into the argument allocas.
 ; CHECK-NEXT: store ptr {{.*}}, ptr %a.addr
 ; CHECK-NEXT: store ptr {{.*}}, ptr %b.addr
 ; CHECK-NEXT: [[frombool:%.*]] = zext i1 {{.*}} to i8
 ; CHECK-NEXT: store i8 %frombool, ptr %doit.addr, align 1
-; CHECK-NEXT: [[stack_base:%.*]] = alloca i64, align 8
+; CHECK-NOT:  alloca i64, align 8
 
 define void @_Z4swapP1SS0_b(ptr %a, ptr %b, i1 zeroext %doit) sanitize_address {
 entry:
diff --git a/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll b/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll
index 4e8466b685689b..8e30fc29382373 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll
@@ -1,4 +1,4 @@
-; RUN: opt -S -passes=asan -asan-use-stack-safety=0 -asan-skip-promotable-allocas=0 %s -o - | FileCheck %s
+; RUN: opt -S -passes=asan -asan-use-stack-safety=0 %s -o - | FileCheck %s
 ; Generated from:
 ; int bar(int y) {
 ;   return y + 2;

Created using spr 1.3.4

vitalybuka · 2024-01-12T02:35:27Z

If getInterestingMemoryOperands never calls
StackSafetyGlobalInfo::getInfo, and a MemIntrinsic is converted to
__asan_memcpy by instrumentMemIntrinsic, when
StackSafetyGlobalInfo::getInfo is called, StackSafetyAnalysis will
consider __asan_memcpy as unsafe, leading to an unnecessary
alloca instrumentation

We need to calculate StackSafetyGlobalInfo before inserting __asan_memcpy

vitalybuka · 2024-01-12T02:45:11Z

And I would expect that neither 8ed1d81 or StackSafety should apply to -O0

MaskRay · 2024-01-12T03:22:34Z

We need to calculate StackSafetyGlobalInfo before inserting __asan_memcpy

Yes, but this is currently not guaranteed. This patch will ensure this property and fix the issue.

And I would expect that neither 8ed1d81 or StackSafety should apply to -O0

@AnnaZaks for 8ed1d81 [asan] Skip promotable allocas to improve performance at -O0

MaskRay · 2024-02-12T18:37:42Z

Ping:)

vitalybuka · 2024-02-15T03:08:12Z

We need to calculate StackSafetyGlobalInfo before inserting __asan_memcpy

Yes, but this is currently not guaranteed. This patch will ensure this property and fix the issue.

Then the correct way to fix this issue to avoid lazy getInfo().
It should be calculated at SSI = &MAM.getResult(M);
Having analysis calculated before modifications is quite important here.

And I would expect that neither 8ed1d81 or StackSafety should apply to -O0

@AnnaZaks for 8ed1d81 [asan] Skip promotable allocas to improve performance at -O0

Turning off isAllocaPromotable is LGTM, I would probably recommend just switch opt<> default to false, and keep it just in case.

I don't see @AnnaZaks active here recently.
@yln @rsundahl instead

MaskRay · 2024-02-15T07:19:37Z

We need to calculate StackSafetyGlobalInfo before inserting __asan_memcpy

Yes, but this is currently not guaranteed. This patch will ensure this property and fix the issue.

Then the correct way to fix this issue to avoid lazy getInfo(). It should be calculated at SSI = &MAM.getResult(M); Having analysis calculated before modifications is quite important here.

We can set -mllvm -stack-safety-run to force getInfo, but it seems that the current lazy getInfo works as intended once this patch is applied.

And I would expect that neither 8ed1d81 or StackSafety should apply to -O0

@AnnaZaks for 8ed1d81 [asan] Skip promotable allocas to improve performance at -O0

Turning off isAllocaPromotable is LGTM, I would probably recommend just switch opt<> default to false, and keep it just in case.

I don't see @AnnaZaks active here recently. @yln @rsundahl instead

Let me rename ClSkipPromotableAllocas (misleading option name even before this patch) to ClInstrumentUninterestingAllocas.
There are some cases that ClInstrumentUninterestingAllocas=0 ignores AllocaInsts that ClInstrumentUninterestingAllocas=1 doesn't.

FWIW I've built a stage-2 -O0 asan clang and a stage-2 -O3 asan clang. The size does not change with or without this patch.

Created using spr 1.3.4

vitalybuka · 2024-02-15T07:33:24Z

llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp

@@ -1279,9 +1278,6 @@ bool AddressSanitizer::isInterestingAlloca(const AllocaInst &AI) {
      (AI.getAllocatedType()->isSized() &&


isInterestingAlloca contains other checks. There is no point to have a flag to enable instrumentation of allocas which we can't instrument.

ClSkipPromotableAllocas on line 1315 is confusing, and maybe unnecessary?
but after your rename it's still confusing

this check applies only to accesses, there is other stuff done to instrument alloca, and ClSkipPromotableAllocas was applied there thru isInterestingAlloca

In ClInstrumentUninterestingAllocas=0 mode, the condition !(SSGI && SSGI->isSafe(AI)) allows to ignore some AllocaInsts that SSGI->stackAccessIsSafe(*Inst) will return false.

My original thought is that ClInstrumentUninterestingAllocas isn't useful and we should just remove it.

If you think ClInstrumentUninterestingAllocas is unnecessary, I will remove it.

Yes, either keep as ClSkipPromotableAllocas=false, just in case, or remove it.
Something similar but not the same is not needed.

vitalybuka · 2024-02-15T07:56:42Z

We can set -mllvm -stack-safety-run to force getInfo, but it seems that the current lazy getInfo works as intended once this patch is applied.

No, we don't need any new flag.
We need to trigger getInfo before any module modification, e.g. at getResult<StackSafetyGlobalAnalysis>
if some function without alloca replaces mem intrinsic, results of calculation of StackSafetyGlobalAnalysis after that will be incorrect (still it's just missed optimization, unnecessary instrumentation).

Any way, no need to do so in this patch.

…e original version of this PR Created using spr 1.3.4

…of the patch Created using spr 1.3.4

vitalybuka · 2024-02-15T17:49:12Z

llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp

@@ -1279,9 +1278,6 @@ bool AddressSanitizer::isInterestingAlloca(const AllocaInst &AI) {
      (AI.getAllocatedType()->isSized() &&


Yes, either keep as ClSkipPromotableAllocas=false, just in case, or remove it.
Something similar but not the same is not needed.

[𝘀𝗽𝗿] initial version

57ce887

Created using spr 1.3.4

MaskRay requested a review from vitalybuka January 7, 2024 04:47

llvmbot added compiler-rt:sanitizer llvm:transforms labels Jan 7, 2024

MaskRay requested a review from kstoimenov January 11, 2024 04:03

rebase after base patch landed

4d02224

Created using spr 1.3.4

MaskRay mentioned this pull request Jan 12, 2024

[asan] Enable StackSafetyAnalysis by default #77210

Merged

vitalybuka requested review from yln and rsundahl February 15, 2024 03:29

MaskRay added 2 commits February 14, 2024 23:24

rename ClSkipPromotableAllocas

4e5aa21

Created using spr 1.3.4

fix cl::desc

46d21cd

Created using spr 1.3.4

vitalybuka reviewed Feb 15, 2024

View reviewed changes

MaskRay added 2 commits February 15, 2024 00:23

remove ClInstrumentUninterestingAllocas. this essentially restores th…

ead3073

…e original version of this PR Created using spr 1.3.4

revert an undeeded clang-format after restoring the original version …

c2eaead

…of the patch Created using spr 1.3.4

vitalybuka approved these changes Feb 15, 2024

View reviewed changes

MaskRay merged commit aa265c4 into users/MaskRay/spr/main.asan-isinterestingalloca-remove-the-isallocapromotable-condition Feb 15, 2024

MaskRay deleted the users/MaskRay/spr/asan-isinterestingalloca-remove-the-isallocapromotable-condition branch February 15, 2024 18:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[asan] isInterestingAlloca: remove the isAllocaPromotable condition #77221

[asan] isInterestingAlloca: remove the isAllocaPromotable condition #77221

Uh oh!

MaskRay commented Jan 7, 2024 •

edited

Loading

Uh oh!

llvmbot commented Jan 7, 2024

Uh oh!

llvmbot commented Jan 7, 2024

Uh oh!

vitalybuka commented Jan 12, 2024

Uh oh!

vitalybuka commented Jan 12, 2024

Uh oh!

MaskRay commented Jan 12, 2024

Uh oh!

MaskRay commented Feb 12, 2024

Uh oh!

vitalybuka commented Feb 15, 2024 •

edited

Loading

Uh oh!

MaskRay commented Feb 15, 2024 •

edited

Loading

Uh oh!

vitalybuka Feb 15, 2024

Uh oh!

vitalybuka Feb 15, 2024

Uh oh!

MaskRay Feb 15, 2024 •

edited

Loading

Uh oh!

vitalybuka Feb 15, 2024

Uh oh!

vitalybuka commented Feb 15, 2024 •

edited

Loading

Uh oh!

vitalybuka Feb 15, 2024

Uh oh!

Uh oh!

		@@ -1279,9 +1278,6 @@ bool AddressSanitizer::isInterestingAlloca(const AllocaInst &AI) {
		(AI.getAllocatedType()->isSized() &&

[asan] isInterestingAlloca: remove the isAllocaPromotable condition #77221

[asan] isInterestingAlloca: remove the isAllocaPromotable condition #77221

Uh oh!

Conversation

MaskRay commented Jan 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Jan 7, 2024

Uh oh!

llvmbot commented Jan 7, 2024

Uh oh!

vitalybuka commented Jan 12, 2024

Uh oh!

vitalybuka commented Jan 12, 2024

Uh oh!

MaskRay commented Jan 12, 2024

Uh oh!

MaskRay commented Feb 12, 2024

Uh oh!

vitalybuka commented Feb 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MaskRay commented Feb 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vitalybuka Feb 15, 2024

Choose a reason for hiding this comment

Uh oh!

vitalybuka Feb 15, 2024

Choose a reason for hiding this comment

Uh oh!

MaskRay Feb 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vitalybuka Feb 15, 2024

Choose a reason for hiding this comment

Uh oh!

vitalybuka commented Feb 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vitalybuka Feb 15, 2024

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MaskRay commented Jan 7, 2024 •

edited

Loading

vitalybuka commented Feb 15, 2024 •

edited

Loading

MaskRay commented Feb 15, 2024 •

edited

Loading

MaskRay Feb 15, 2024 •

edited

Loading

vitalybuka commented Feb 15, 2024 •

edited

Loading