https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/119365
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -594,9 +580,9 @@ BasicAAResult::DecomposeGEPExpression(const Value *V, const
DataLayout &DL,
SearchTimes++;
const Instruction *CxtI = dyn_cast(V);
- unsigned MaxIndexSize = DL.getMaxIndexSizeInBits();
aeubanks wrote:
looks like `getMaxIndexSizeInBits
aeubanks wrote:
I believe the failure reported in the original bot is only under expensive
checks (`-DLLVM_ENABLE_EXPENSIVE_CHECKS=ON`)
https://github.com/llvm/llvm-project/pull/113780
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
aeubanks wrote:
perhaps the `flock` cmake check doesn't work on windows for some reason? maybe
wrong include?
https://github.com/llvm/llvm-project/pull/111332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
aeubanks wrote:
I believe Chrome is also seeing many test failures due to this
(https://crbug.com/374115887), although I haven't yet confirmed it's due to
this specific commit.
https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits mailing l
https://github.com/aeubanks approved this pull request.
relanding lgtm since the exposed issue was fixed
https://github.com/llvm/llvm-project/pull/112749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
aeubanks wrote:
I've reverted this in 9e6d24f61f3a6730465f3427463dd958cdcd8b9a
https://github.com/llvm/llvm-project/pull/91101
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Arthur Eubanks
Date: 2024-10-16T21:21:34Z
New Revision: 9e6d24f61f3a6730465f3427463dd958cdcd8b9a
URL:
https://github.com/llvm/llvm-project/commit/9e6d24f61f3a6730465f3427463dd958cdcd8b9a
DIFF:
https://github.com/llvm/llvm-project/commit/9e6d24f61f3a6730465f3427463dd958cdcd8b9a.diff
LOG
aeubanks wrote:
This causes broken IR:
```
$ opt -O3 -disable-output /tmp/a.ll
Range bit width must match type bit width!
tail call void @llvm.memset.p0.i64(ptr noundef align 1 %dst, i8 noundef
range(i32 0, 256) %v8, i64 noundef range(i64 -2147483648, 21474836
aeubanks wrote:
for such a wide-reaching change, it would have been nice to add the new
function in one commit, update users in other commits, then remove the old
function in one last commit. makes it easier to revert the removal of the old
function, and makes it easier for out of tree users t
aeubanks wrote:
ah there's a stack trace in an asserts build of clang
```
F 00:00:1728077756.9778713296 logging.cc:62] assert.h assertion failed
at
third_party/llvm/llvm-project/clang/lib/Sema/SemaTemplateInstantiate.cpp:4602
in llvm::PointerUnion
*clang::LocalInstantiationScope::find
aeubanks wrote:
this has also caused the following issue to pop up in our modules build
```
error: variable 'param' cannot be implicitly captured in a lambda with no
capture-default specified
```
hopefully the error provides some guidance for where to look, but I can try to
get a reduced repr
https://github.com/aeubanks commented:
I see that MMI really is a Codegen concept and not a Target concept, so that's
why it takes an LLVMTargetMachine instead of TargetMachine. However, the
`static_cast`s everywhere are extremely unfortunate. And it doesn't make sense
to make the return type
https://github.com/aeubanks commented:
ah there's more context in https://reviews.llvm.org/D123964
https://github.com/llvm/llvm-project/pull/110443
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
@@ -1162,6 +1165,7 @@ void EmitAssemblyHelper::RunCodegenPipeline(
// does not work with the codegen pipeline.
// FIXME: make the new PM work with the codegen pipeline.
legacy::PassManager CodeGenPasses;
+ std::unique_ptr MMI;
aeubanks wrote:
can this j
@@ -106,16 +106,18 @@ class MachineModuleInfo {
const Function *LastRequest = nullptr; ///< Used for shortcut/cache.
MachineFunction *LastResult = nullptr; ///< Used for shortcut/cache.
- MachineModuleInfo &operator=(MachineModuleInfo &&MMII) = delete;
+ /// Deleted copy
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/110443
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks commented:
I'm still trying to wrap my head around LLVMTargetMachine vs TargetMachine, let
me do some reading
https://github.com/llvm/llvm-project/pull/110443
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
aeubanks wrote:
hmm yeah it does seem that `MCContext` is hard to unentangle from
`MMI`/`MachineFunction`
is it possible to split out the "MMIWP doesn't own MMI" change? that seems less
controversial and easier to review/merge and makes the `MCContext` changes
easier to look at
https://githu
aeubanks wrote:
sorry for the delay
after looking at MMI/MCContext, I agree that MMI shouldn't own MCContext, but
do we even need a reference from MMI to MCContext? they are different layers of
codegen IIUC. if it's possible to completely separate them we should do that
(please correct me if
Valentin Clement =?utf-8?b?KOODkOODrOODsw=?=,Kyungwoo Lee
,Dmitry
Polukhin ,Dmitry Polukhin
Message-ID:
In-Reply-To:
aeubanks wrote:
here's something reduced, let me know if you need the command to create the pch
file as well
```
https://github.com/llvm/llvm-project/pull/104512
_
https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/108452
With the legacy runtime directory layout, the runtime libraries are under
`lib/clang/20/lib/windows` and have an arch suffix.
>From c45f5df3c0ba7afd6c5e14e8e49ffa853abc7147 Mon Sep 17 00:00:00 2001
From: Arthu
Valentin Clement =?utf-8?b?KOODkOODrOODsw==?=,Kyungwoo Lee
,Dmitry
Polukhin ,Dmitry Polukhin
Message-ID:
In-Reply-To:
aeubanks wrote:
let me try to come up with a reduced repro
https://github.com/llvm/llvm-project/pull/104512
___
cfe-commits mail
aeubanks wrote:
this looks like it has false positives: https://crbug.com/366074092
can we revert in the meantime?
https://github.com/llvm/llvm-project/pull/107213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
@@ -136,7 +160,7 @@ append_list_if(MINGW "${MINGW_LIBRARIES}" ASAN_DYNAMIC_LIBS)
add_compiler_rt_object_libraries(RTAsan_dynamic
OS ${SANITIZER_COMMON_SUPPORTED_OS}
ARCHS ${ASAN_SUPPORTED_ARCH}
- SOURCES ${ASAN_SOURCES} ${ASAN_CXX_SOURCES}
+ SOURCES ${ASAN_SOURCES}
--
aeubanks wrote:
previous passing output
```
2: =
3: ==7382==ERROR: AddressSanitizer: requested allocation size 0x101
(0x1001008 after adjustments for alignment, red zones etc.) exceeds maximum
supported size o
aeubanks wrote:
I think this is also somehow affecting asan tests on macos:
https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/2034/
was able to reproduce locally
`build/cmake/runtimes/runtimes-bins/compiler-rt/test/sanitizer_common/asan-arm64-Darwin/allocator_returns_null.cpp`
faili
Valentin Clement =?utf-8?b?KOODkOODrOODsw=?=,Kyungwoo Lee
,Dmitry
Polukhin ,Dmitry Polukhin
Message-ID:
In-Reply-To:
aeubanks wrote:
this is causing a crash with precompiled headers. I can try to reduce, but
hopefully the problem is obvious from this assert/stack trace?
```
clang++: ../..
@@ -326,24 +326,11 @@ static bool shouldTrackFirstArgument(const FunctionDecl
*FD) {
return false;
}
-static bool implicitObjectParamIsLifetimeBound(const FunctionDecl *FD) {
- const TypeSourceInfo *TSI = FD->getTypeSourceInfo();
- if (!TSI)
-return false;
- // Don't
aeubanks wrote:
There needs to be a flag to opt out of this to not break everybody who is
currently using unsafe-buffer-usage. #105383 seems to do that, but it really
should be in this same PR. Can this be reverted and relanded with the flag?
https://github.com/llvm/llvm-project/pull/101583
__
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/106790
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks updated
https://github.com/llvm/llvm-project/pull/106790
>From a469c523921c3bcb3a8e2a6ad5eaa856a6035449 Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Fri, 30 Aug 2024 20:14:18 +
Subject: [PATCH 1/2] [PGO][Pipeline] Enable PGOForceFunctionAttrs in PGO
optim
aeubanks wrote:
I'm just back from vacation, taking a look
looks like this has merge conflicts
could you simplify the commit title (maybe move some details into the
description)
https://github.com/llvm/llvm-project/pull/105541
___
cfe-commits mailin
aeubanks wrote:
for future reference,
https://github.com/llvm/llvm-project/commit/3cd67eeca28ab1084d02b7976de1af4c4c8d37d5
fixes a miscompile that this patch uncovered
https://github.com/llvm/llvm-project/pull/92666
___
cfe-commits mailing list
cfe-c
@@ -907,6 +945,76 @@ void StreamChecker::preWrite(const FnDescription *Desc,
const CallEvent &Call,
C.addTransition(State);
}
+static std::optional getPointeeType(const MemRegion *R) {
+ if (!R)
+return std::nullopt;
+ if (const auto *ER = dyn_cast(R))
+return ER-
aeubanks wrote:
@alexey-bataev
https://github.com/llvm/llvm-project/pull/94559
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
SLPVectorizer can introduce `llvm.tan.v2f32`. For example, running `opt -O3` on
the following introduces `llvm.tan.v2f32`
```
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7-unknown-linux-android26"
; Function Attrs: null_pointe
aeubanks wrote:
> @aeubanks I'll revert. Is this example C or C++?
C++
https://github.com/llvm/llvm-project/pull/94216
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
reduced:
```
struct Lock {};
struct A {
Lock lock;
union {
bool b __attribute__((guarded_by(lock)));
};
};
```
seems like a regression, can we revert for now?
https://github.com/llvm/llvm-project/pull/94216
aeubanks wrote:
this seems to have broken code like
[this](https://crsrc.org/c/base/allocator/partition_allocator/src/partition_alloc/random.cc;drc=36293863bf9bbc8131797eb8f4d2bafe8af3de79;l=33)
with
```
../../base/allocator/partition_allocator/src/partition_alloc/random.cc:33:69:
error: inval
aeubanks wrote:
This was with `-DLLVM_ENABLE_LLD=ON`, so probably not? I'm guessing there's
some CMake logic that doesn't fit with clang-repl's expectation of symbol
availability, but that may be wrong.
https://github.com/llvm/llvm-project/pull/89811
___
aeubanks wrote:
I believe this has exposed a preexisting issue in isel with tan:
```
$ cat /tmp/b.ll
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7-unknown-linux-android26"
define <2 x float> @g() {
entry:
%0 = call <2 x float> @llvm.tan.v2f
aeubanks wrote:
So actually even the `export_executable_symbols_for_plugins` doesn't fix our
bots. I've narrowed it down to `-DLLVM_ENABLE_PIC=ON/OFF`. Perhaps we're not
exporting symbols when `-DLLVM_ENABLE_PIC=OFF`.
https://github.com/llvm/llvm-project/pull/89811
https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/95126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
thanks for doing this!
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks approved this pull request.
this PR looks good, and further dropping the fold is also good
https://github.com/llvm/llvm-project/pull/93823
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
aeubanks wrote:
looks like `CodeGen/AMDGPU/llc-pipeline.ll` is failing
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/93697
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1030,6 +1036,12 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
Phase != ThinOrFullLTOPhase::ThinLTOPostLink)
MPM.addPass(SampleProfileProbePass(TM));
+ // Instrument function entry and exit before all inlining.
+ if (!isLTOPostLink(
@@ -1030,6 +1036,12 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
Phase != ThinOrFullLTOPhase::ThinLTOPostLink)
MPM.addPass(SampleProfileProbePass(TM));
+ // Instrument function entry and exit before all inlining.
+ if (!isLTOPostLink(
@@ -31,6 +31,10 @@
; CHECK-NEXT: AArch64 Stack Tagging
; CHECK-NEXT: SME ABI Pass
; CHECK-NEXT: Exception handling preparation
+; CHECK-NEXT: Dominator Tree Construction
+; CHECK-NEXT: Basic Alias Analysis (stateless AA impl)
+; CHECK-NEXT: F
@@ -1030,6 +1036,12 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
Phase != ThinOrFullLTOPhase::ThinLTOPostLink)
MPM.addPass(SampleProfileProbePass(TM));
+ // Instrument function entry and exit before all inlining.
+ if (!isLTOPostLink(
@@ -1,5 +1,5 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -debug-info-kind=standalone
-emit-llvm -o - %s -finstrument-functions | FileCheck %s
aeubanks wrote:
this should also not be testing the pass and should have -disable-llvm-passes
https://github.c
https://github.com/aeubanks commented:
looks pretty good, can you update the commit title to something like
`[EntryExitInstrumenter] Move passes out of clang into LLVM default pipelines`
I've added test coverage for mcount-aix in
3ec57a7ed60a19c5e3e18655e19c997a469d10ec, can you merge that in?
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,25 +1,13 @@
// RUN: %clang_cc1 -pg -triple powerpc-ibm-aix7.2.0.0 -emit-llvm %s -o - |
FileCheck %s
aeubanks wrote:
also -disable-llvm-passes here
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits
@@ -1,37 +1,27 @@
// REQUIRES: x86-registered-target
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finstrument-functions -O0
-o - -emit-llvm %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finstrument-functions -O2
-o - -emit-llvm %s | FileCheck %s
-
@@ -1,37 +1,27 @@
// REQUIRES: x86-registered-target
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finstrument-functions -O0
-o - -emit-llvm %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finstrument-functions -O2
-o - -emit-llvm %s | FileCheck %s
-
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks commented:
forgot to hit "submit review"...
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,37 +1,27 @@
// REQUIRES: x86-registered-target
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finstrument-functions -O0
-o - -emit-llvm %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finstrument-functions -O2
-o - -emit-llvm %s | FileCheck %s
-
@@ -0,0 +1,29 @@
+; RUN: llc -mtriple=x86_64-- -O0 < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-- -O1 < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-- -O2 < %s | FileCheck %s
+
+; The codegen should insert post-inlining instrumentation calls and should not
+; insert pre-inlini
@@ -0,0 +1,44 @@
+; RUN: opt -passes="default" -S < %s | FileCheck -check-prefix=PRELTO %s
+; RUN: opt -passes="default" -S < %s | FileCheck -check-prefix=PRELTO %s
+; RUN: opt -passes="thinlto-pre-link,thinlto" -S < %s | FileCheck
-check-prefix=PRELTO %s
+; RUN: opt -passes="thi
@@ -1,41 +0,0 @@
-// REQUIRES: arm-registered-target,aarch64-registered-target
-
-// RUN: %clang -target armv7-unknown-none-eabi -pg -S -emit-llvm -o - %s |
FileCheck %s -check-prefixes=CHECK,UNSUPPORTED
-// RUN: %clang -target armv7-unknown-none-eabi -pg -meabi gnu -S -emit-llvm
@@ -0,0 +1,44 @@
+; RUN: opt -passes="default" -S < %s | FileCheck -check-prefix=PRELTO %s
aeubanks wrote:
`PRELTO` isn't quite accurate since we also instrument in the default
pipelines, I'd use `INSTRUMENT`/`NOINSTRUMENT` or even just `YES`/`NO` :)
https://gi
@@ -0,0 +1,44 @@
+; RUN: opt -passes="default" -S < %s | FileCheck -check-prefix=PRELTO %s
+; RUN: opt -passes="default" -S < %s | FileCheck -check-prefix=PRELTO %s
+; RUN: opt -passes="thinlto-pre-link,thinlto" -S < %s | FileCheck
-check-prefix=PRELTO %s
aeubank
https://github.com/aeubanks approved this pull request.
awesome, thanks!
https://github.com/llvm/llvm-project/pull/92953
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,29 @@
+; RUN: llc -mtriple=x86_64-- -O0 < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-- -O1 < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-- -O2 < %s | FileCheck %s
+
+; The codegen should insert post-inlining instrumentation calls and should not
+; insert pre-inlini
@@ -0,0 +1,31 @@
+; RUN: opt -passes="default" -S < %s | FileCheck %s
+; RUN: opt -passes="thinlto-pre-link" -S < %s | FileCheck %s
+; RUN: opt -passes="thinlto-pre-link,thinlto" -S < %s | FileCheck %s
+
+target triple = "x86_64-unknown-linux"
+
+define void @leaf_function() #0 {
@@ -0,0 +1,31 @@
+; RUN: opt -passes="default" -S < %s | FileCheck %s
aeubanks wrote:
should also test `O0` versions of these, plus `lto-pre-link`
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing
@@ -0,0 +1,31 @@
+; RUN: opt -passes="default" -S < %s | FileCheck %s
+; RUN: opt -passes="thinlto-pre-link" -S < %s | FileCheck %s
+; RUN: opt -passes="thinlto-pre-link,thinlto" -S < %s | FileCheck %s
aeubanks wrote:
no need to run `thinlto` here, but we should
aeubanks wrote:
it seems like this should just be in the default codegen pipeline? you'd need
to change the pass to bail out early if there are no relevant intrinsics (by
checking if the module contains the intrinsic declaration) to not affect
compile times
https://github.com/llvm/llvm-projec
https://github.com/aeubanks approved this pull request.
we've resolved the performance regression from the previous patch internally,
thanks for waiting!
https://github.com/llvm/llvm-project/pull/89872
___
cfe-commits mailing list
cfe-commits@lists.ll
@@ -0,0 +1,86 @@
+//===-- llvm/GEPNoWrapFlags.h - NoWrap flags for GEPs ---*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
https://github.com/aeubanks approved this pull request.
thanks, I think abstracting out GEPNoWrapFlags is good
https://github.com/llvm/llvm-project/pull/90824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
@@ -0,0 +1,86 @@
+//===-- llvm/GEPNoWrapFlags.h - NoWrap flags for GEPs ---*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/90824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1028,6 +1029,14 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
Phase != ThinOrFullLTOPhase::ThinLTOPostLink)
MPM.addPass(SampleProfileProbePass(TM));
+ // Instrument function entry and exit before all inlining.
+ if (Phase != ThinOr
https://github.com/aeubanks commented:
looks pretty good to me
for testing the pre-inliner one, we should add some tests in
`llvm/test/Transforms/EntryExitInstrumenter/` that invoke things like `opt
-passes='default'`, `opt -passes='thinlto-pre-link'`, `opt
-passes='thinlto'` to make sure tha
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -101,6 +101,7 @@ void initializeEarlyMachineLICMPass(PassRegistry&);
void initializeEarlyTailDuplicatePass(PassRegistry&);
void initializeEdgeBundlesPass(PassRegistry&);
void initializeEHContGuardCatchretPass(PassRegistry &);
+void initializeEntryExitInstrumenterPass(PassReg
aeubanks wrote:
can you add links to https://reviews.llvm.org/D97608,
https://github.com/rust-lang/rust/issues/92109,
https://github.com/llvm/llvm-project/issues/52853
https://github.com/llvm/llvm-project/pull/92171
___
cfe-commits mailing list
cfe-c
@@ -135,6 +138,65 @@ static bool runOnFunction(Function &F, bool PostInlining) {
return Changed;
}
+namespace {
+struct EntryExitInstrumenter : public FunctionPass {
+ static char ID;
+ EntryExitInstrumenter() : FunctionPass(ID) {
+initializeEntryExitInstrumenterPass(*
@@ -670,9 +670,6 @@ void CodeGenPassBuilder::addIRPasses(
!Opt.DisablePartialLibcallInlining)
addPass(PartiallyInlineLibCallsPass());
- // Instrument function entry and exit, e.g. with calls to mcount().
- addPass(EntryExitInstrumenterPass(/*PostInlining=*/true));
@@ -1016,6 +1000,11 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!IsThinLTOPostLink) {
addSanitizers(TargetTriple, CodeGenOpts, LangOpts, PB);
addKCFIPass(TargetTriple, LangOpts, PB);
+ PB.registerPipelineStartEPCallback(
aeuban
aeubanks wrote:
> -fstrict-vtable-pointers IS experimental, but if you recall, this particular
> optimization was added to -fstrict-vtable-pointers because of the effects it
> had on compile-time, not because of correctness issues.
can you clarify what you mean by "this particular optimization
aeubanks wrote:
adding assumes in general has issues:
https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609
do you have proof that this change helps binaries and doesn't regress things? I
have a feeling this will regress many things. `-fstrict-vtable-pointers` is
still somewhat e
aeubanks wrote:
should be fine to revert as much as you want in a single PR, just make sure to
mention what you're reverting in the description
https://github.com/llvm/llvm-project/pull/91620
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
aeubanks wrote:
Chromium is also seeing similar breakages. @sdkrystian is this breaking valid
code? I can't tell from your latest comment. (if it is breaking valid code we
should revert)
https://github.com/llvm/llvm-project/pull/91498
___
cfe-commits
aeubanks wrote:
btw we're still looking into a performance regression caused by #68882 that
still repros with LLVM head, even after the SROA enhancements. this patch looks
good, but can we hold off a bit on submitting this?
https://github.com/llvm/llvm-project/pull/89872
__
@@ -944,43 +943,18 @@ Constant *SymbolicallyEvaluateGEP(const GEPOperator *GEP,
return ConstantExpr::getIntToPtr(C, ResTy);
}
- // Otherwise form a regular getelementptr. Recompute the indices so that
- // we eliminate over-indexing of the notional static type array bo
@@ -944,43 +943,18 @@ Constant *SymbolicallyEvaluateGEP(const GEPOperator *GEP,
return ConstantExpr::getIntToPtr(C, ResTy);
}
- // Otherwise form a regular getelementptr. Recompute the indices so that
- // we eliminate over-indexing of the notional static type array bo
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/89298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/89298
To be removed and promoted to a proper driver flag if experiments turn out
fruitful.
For now, this can be experimented with `-mllvm
-pgo-cold-func-opt=[optsize|minsize|optnone|default] -mllvm
-enable-pgo-forc
https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/88793
To be removed and promoted to a proper driver flag if experiments turn out
fruitful.
Original LLVM patch for this functionality: #69030
>From 52cd9974be908bf693832012e56e945e9e34f389 Mon Sep 17 00:00:00 2001
F
https://github.com/aeubanks approved this pull request.
lg, but update the commit message `Pull Request:
https://github.com/llvm/llvm-project/pull/87866`, that's obsolete
https://github.com/llvm/llvm-project/pull/88661
___
cfe-commits mailing list
cfe
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/87906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 460 matches
Mail list logo
