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
@@ -907,6 +945,76 @@ void StreamChecker::preWrite(const FnDescription *Desc,
const CallEvent ,
C.addTransition(State);
}
+static std::optional getPointeeType(const MemRegion *R) {
+ if (!R)
+return std::nullopt;
+ if (const auto *ER = dyn_cast(R))
+return
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:
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:
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>
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
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
@@ -1030,6 +1036,12 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
Phase != ThinOrFullLTOPhase::ThinLTOPostLink)
MPM.addPass(SampleProfileProbePass(TM));
+ // Instrument function entry and exit before all inlining.
+ if
@@ -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:
@@ -1030,6 +1036,12 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
Phase != ThinOrFullLTOPhase::ThinLTOPostLink)
MPM.addPass(SampleProfileProbePass(TM));
+ // Instrument function entry and exit before all inlining.
+ if
@@ -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.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
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
___
@@ -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
@@ -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
@@ -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
@@ -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` :)
@@ -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
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
@@ -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
@@ -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/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
@@ -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:
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
@@ -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:
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 !=
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
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
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
@@ -135,6 +138,65 @@ static bool runOnFunction(Function , bool PostInlining) {
return Changed;
}
+namespace {
+struct EntryExitInstrumenter : public FunctionPass {
+ static char ID;
+ EntryExitInstrumenter() : FunctionPass(ID) {
+
@@ -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(
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
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
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
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
___
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
@@ -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
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
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
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
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
aeubanks wrote:
yeah that patch makes those test pass with this PR, lgtm
(you could also test locally by touching the files I mentioned above, e.g. even
just `touch lib/clang/19/lib/linux/libclang_rt.builtins-aarch64-android.a`
repro'd the test failure on my machine)
Author: Arthur Eubanks
Date: 2024-04-10T23:41:51Z
New Revision: be10070f91b86a6f126d2451852242bfcb2cd366
URL:
https://github.com/llvm/llvm-project/commit/be10070f91b86a6f126d2451852242bfcb2cd366
DIFF:
https://github.com/llvm/llvm-project/commit/be10070f91b86a6f126d2451852242bfcb2cd366.diff
aeubanks wrote:
it seems that the test depends on if certain android runtime libraries are
present or not in the resource dir (without per-target runtime directory since
that's still an issue on Android). perhaps the tests need `-resource-dir` to
make them more hermetic?
anyway, will revert,
aeubanks wrote:
this seemes to be causing some test failures for us:
https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8751043232043110529/+/u/package_clang/stdout?format=raw
```
TEST 'Clang :: Driver/linux-ld.c' FAILED
RUN: at line
https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/87987
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aeubanks edited
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
aeubanks wrote:
> I'd suggest adding bitcode upgrade if it isn't too hard (I don't think it
> should be?)
done
https://github.com/llvm/llvm-project/pull/87906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/aeubanks updated
https://github.com/llvm/llvm-project/pull/87906
>From 7a9df42b4c4f4f1b02dc3158d24800f3d4b68d8f Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Sun, 7 Apr 2024 05:29:36 +
Subject: [PATCH 1/2] [clang][llvm] Remove "implicit-section-name" attribute
aeubanks wrote:
this probably needs bitcode upgrade?
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
https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/87906
D33412/D33413 introduced this to support a clang pragma to set section names
for a symbol depending on if it would be placed in bss/data/rodata/text, which
may not be known until the backend. However, for text
aeubanks wrote:
ah I see. I feel like this should be a more principled approach that other
sanitizers also share, as you've mentioned as an alternative. do people not
care about other sanitizers in production?
(I'm going to be OOO for a week, so someone else will need to review)
aeubanks wrote:
> We already have similar stuff:
>
> ```
> if (PGOOpt && Phase != ThinOrFullLTOPhase::ThinLTOPostLink &&
> !PGOOpt->MemoryProfile.empty())
> MPM.addPass(MemProfUsePass(PGOOpt->MemoryProfile, PGOOpt->FS));
> ```
checking for ThinLTO pre/post link is a correctness thing
aeubanks wrote:
> > why can't hwasan and PGO instrumentation coexist?
>
> They can, but binary is like 5x times slower, on top of 10x slowdown of PGO
> instrumentation. (don't quote me on these numbers, they are from large but
> single benchmark, still it's very slow)
>
If it's usable as a
aeubanks wrote:
why can't hwasan and PGO instrumentation coexist?
and this seems like it should be an error at the clang driver level, instead of
silently turning off one of the requested features
https://github.com/llvm/llvm-project/pull/86739
___
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/86039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5804,7 +5804,7 @@ void Clang::ConstructJob(Compilation , const JobAction
,
} else if (Triple.getArch() == llvm::Triple::x86_64) {
Ok = llvm::is_contained({"small", "kernel", "medium", "large", "tiny"},
CM);
-} else if
https://github.com/aeubanks updated
https://github.com/llvm/llvm-project/pull/86039
>From bba8e4003c4ccc36497e62ad1696197e6987525c Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Wed, 20 Mar 2024 23:36:35 +
Subject: [PATCH 1/2] [clang][SPIRV] Ignore -mcmodel
The code model doesn't
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/86039
___
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/86039
The code model doesn't affect the sub-compilation, so don't check it.
Followup to #70740.
>From bba8e4003c4ccc36497e62ad1696197e6987525c Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Wed, 20 Mar 2024
aeubanks wrote:
> > > yes, but I'd like to that after we collect feedback from first users
> >
> >
> > They are introduced by earlier transformations
> > Note: I'd like to have special intrinsic for this optimization. When we
> > have it, we likely don't need this SimplifyCFG.
>
> lgtm with
https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/84214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
> > yes, but I'd like to that after we collect feedback from first users
>
> They are introduced by earlier transformations
>
> Note: I'd like to have special intrinsic for this optimization. When we have
> it, we likely don't need this SimplifyCFG.
lgtm with a comment added
@@ -744,6 +750,21 @@ static void addSanitizers(const Triple ,
// LastEP does not need GlobalsAA.
PB.registerOptimizerLastEPCallback(SanitizersCallback);
}
+
+ if (ClRemoveTraps) {
+// We can optimize after inliner, and PGO profile matching. The hook below
+
@@ -744,6 +750,21 @@ static void addSanitizers(const Triple ,
// LastEP does not need GlobalsAA.
PB.registerOptimizerLastEPCallback(SanitizersCallback);
}
+
+ if (ClRemoveTraps) {
+// We can optimize after inliner, and PGO profile matching. The hook below
+
@@ -744,6 +750,21 @@ static void addSanitizers(const Triple ,
// LastEP does not need GlobalsAA.
PB.registerOptimizerLastEPCallback(SanitizersCallback);
}
+
+ if (ClRemoveTraps) {
+// We can optimize after inliner, and PGO profile matching. The hook below
+
@@ -744,6 +750,21 @@ static void addSanitizers(const Triple ,
// LastEP does not need GlobalsAA.
PB.registerOptimizerLastEPCallback(SanitizersCallback);
}
+
+ if (ClRemoveTraps) {
+// We can optimize after inliner, and PGO profile matching. The hook below
+
aeubanks wrote:
the only use of this is GlobalSplit, and it cares about ranges relative to the
GlobalVariable, so if we're not planning on using this in more cases then I'd
say relative to the source pointer makes sense.
not sure if inrange would ever be useful for more than GlobalSplit, like
aeubanks wrote:
is there a long term plan to add a driver flag for this?
https://github.com/llvm/llvm-project/pull/84214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
> Oh, thanks @nikic for that data point. Let me try to avoid the overhead, I'll
> put up a patch tomorrow morning.
Did this ever happen?
https://github.com/llvm/llvm-project/pull/78445
___
cfe-commits mailing list
aeubanks wrote:
Sorry, I thought I had waited long enough and that the previous comments were
addressed. Will address your comments in a follow-up.
> This is good to go only because it's off by default. Otherwise it's not.
> Sample PGO profile has inline context, so in the profile, we may
aeubanks wrote:
for my information, which version of Visual Studio are you using?
https://github.com/llvm/llvm-project/pull/81649
___
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/81649
___
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/81649
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 427 matches
Mail list logo
