@@ -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
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/81534
___
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/69030
___
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/81534
___
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/81534
___
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/81534
___
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/81533
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
seeing if Windows CI catches anything
https://github.com/llvm/llvm-project/pull/81534
___
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/81534
Added in 26670dcba1609574cba5942aff78ff97b567c5f3.
>From c659a573a066809473ebb36421e612dcdcda5aef Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Mon, 12 Feb 2024 21:01:39 +
Subject: [PATCH] [clang]
https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/81533
PR #71709 broke the Linux PIE build with `undefined symbol: alloca` errors.
With the newly included `clang/Basic/Builtins.h` in that PR, it surfaces an
issue with a combination of two previous patches.
aeubanks wrote:
https://github.com/llvm/llvm-project/issues/4885 for why `#undef alloca` was
added
https://github.com/llvm/llvm-project/pull/71709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
aeubanks wrote:
I'll send out a PR to remove that code, and potentially also remove the `#undef
alloca` separately
https://github.com/llvm/llvm-project/pull/71709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
aeubanks wrote:
this seems to break `-fPIE` builds of clang on Linux with the following:
```
ld.lld: error: undefined symbol: alloca
>>> referenced by cc1_main.cpp
>>>
>>> tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o:(ensureStackAddressSpace())
```
the call to
aeubanks wrote:
> > > Good example. This pass should be run post-inline. @aeubanks, any reason
> > > we want to run it early in the pipeline?
> >
> >
> > We want the main function simplification pipeline to see these function
> > attributes because some optimizations trigger or don't trigger
aeubanks wrote:
> Good example. This pass should be run post-inline. @aeubanks, any reason we
> want to run it early in the pipeline?
We want the main function simplification pipeline to see these function
attributes because some optimizations trigger or don't trigger depending on the
aeubanks wrote:
I don't understand, if you're saying the profile is accurate, then those
functions are actually cold, so we should be able to mark them as optsize?
https://github.com/llvm/llvm-project/pull/69030
___
cfe-commits mailing list
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/69030
___
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/69030
>From e52a811c3b643548837b4e630e8293a0b6857ad4 Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Fri, 13 Oct 2023 14:40:28 -0700
Subject: [PATCH 1/6] [PGO] Add ability to mark cold functions as
@@ -0,0 +1,73 @@
+//===--===//
+//
+// 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:
aeubanks wrote:
> FWIW we've tried this with sampling PGO in the past. While on paper this
> seems like an obvious thing to do, in reality aggressively tuning down opt
> level for cold functions can lead to regression since profile isn't always
> accurate.
>
> That said, as long as this
aeubanks wrote:
> How does this relate to the existing `shouldOptimizeForSize(Function&, ...)`
> and `shouldOptimizeForSize(MachineFunction&, ...)` APIs which appear to
> provide similar functionality at a first glance. If they are the same, then
> we should have a plan in place to cleanup
@@ -0,0 +1,7 @@
+/// Some target-specific options are ignored for GPU, so %clang exits with
code 0.
+// DEFINE: %{gpu_opts} = --cuda-gpu-arch=sm_60
--cuda-path=%S/Inputs/CUDA/usr/local/cuda --no-cuda-version-check
aeubanks wrote:
these defines seem overkill
1 - 100 of 406 matches
Mail list logo
