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
@@ -1127,6 +1134,11 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
if (EnableSyntheticCounts && !PGOOpt)
MPM.addPass(SyntheticCountsPropagation());
+ if (EnableMarkColdFunctions && PGOOpt &&
+ (PGOOpt->Action == PGOOptions::SampleUse
@@ -0,0 +1,65 @@
+//===--===//
+//
+// 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 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/5] [PGO] Add ability to mark cold functions as
@@ -1127,6 +1134,11 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
if (EnableSyntheticCounts && !PGOOpt)
MPM.addPass(SyntheticCountsPropagation());
+ if (EnableMarkColdFunctions && PGOOpt &&
+ (PGOOpt->Action == PGOOptions::SampleUse
@@ -0,0 +1,28 @@
+//===- MarkColdFunctions.h - *- 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 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/3] [PGO] Add ability to mark cold functions as
https://github.com/aeubanks approved this pull request.
https://github.com/llvm/llvm-project/pull/78610
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
I'm missing the full context behind this patch, but code seems reasonable
https://github.com/llvm/llvm-project/pull/78610
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
aeubanks wrote:
should this have had a test? I'm trying to do the same thing for
`-mlarge-data-threshold` and am trying to find an appropriate place to add a
test
https://github.com/llvm/llvm-project/pull/70740
___
cfe-commits mailing list
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/73045
___
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/73045
>From 0145020ef2a803ec797e42f95bacde05dc32eac1 Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Tue, 21 Nov 2023 14:01:04 -0800
Subject: [PATCH 1/3] [lld/ELF] Hint if R_X86_64_PC32 overflows and references
aeubanks wrote:
sorry, I keep missing notifications, will find a repro
https://github.com/llvm/llvm-project/pull/75841
___
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/73045
>From 0145020ef2a803ec797e42f95bacde05dc32eac1 Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Tue, 21 Nov 2023 14:01:04 -0800
Subject: [PATCH 1/2] [lld/ELF] Hint if R_X86_64_PC32 overflows and references
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/77958
___
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/77958
___
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/77958
>From 3a54757173faffe07da55223c52621691afad54d Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Fri, 12 Jan 2024 18:13:06 +
Subject: [PATCH 1/2] [clang] Adjust -mlarge-data-threshold handling
Make it
https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/77958
Make it apply to x86-64 medium and large code models since that's what the
backend does.
Warn if it's used for x86-32.
Default to 0, let the driver set it to 65536 for the medium code model
if one is not
aeubanks wrote:
is the clang invocation in the logs I posted sufficient?
https://github.com/llvm/llvm-project/pull/75841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
the clang changes should be split into a followup patch
https://github.com/llvm/llvm-project/pull/76868
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
ah it's because we something like
```
[cfi-unrelated-cast|cfi-derived-cast]
src:*third_party/vulkan_memory_allocator/include/vk_mem_alloc.h
```
it seems like the new system doesn't match
`[cfi-unrelated-cast|cfi-derived-cast]`
https://github.com/llvm/llvm-project/pull/74809
aeubanks wrote:
the file name is `vk_mem_alloc.h` so that shouldn't be the issue
https://github.com/llvm/llvm-project/pull/74809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
This caused some ignorelist changes, e.g.
`src:*third_party/vulkan_memory_allocator/include/vk_mem_alloc.h`
didn't work anymore and the opt-out made it work again. Still investigating why.
https://github.com/llvm/llvm-project/pull/74809
aeubanks wrote:
I've reverted this, hopefully the command line in the failing invocation I gave
is enough to repro the regression, otherwise lmk what else I can do to help
repro
https://github.com/llvm/llvm-project/pull/75841
___
cfe-commits mailing
Author: Arthur Eubanks
Date: 2024-01-02T18:09:16Z
New Revision: d34901f30b8b7ac8fe1437eeb588da6805b27cfb
URL:
https://github.com/llvm/llvm-project/commit/d34901f30b8b7ac8fe1437eeb588da6805b27cfb
DIFF:
https://github.com/llvm/llvm-project/commit/d34901f30b8b7ac8fe1437eeb588da6805b27cfb.diff
aeubanks wrote:
same in our stage 2 build
```
[4643/5157] Building CXX object
tools/dsymutil/CMakeFiles/dsymutil.dir/CFBundle.cpp.o
FAILED: tools/dsymutil/CMakeFiles/dsymutil.dir/CFBundle.cpp.o
/Volumes/Work/s/w/ir/cache/builder/src/third_party/llvm-bootstrap-install/bin/clang++
https://github.com/aeubanks approved this pull request.
I think this is a good direction to go, lgtm
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
aeubanks wrote:
still seeing Android errors
```
[275/404] Building C object
CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model/aarch64.c.o
FAILED: CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model/aarch64.c.o
/b/s/w/ir/cache/builder/src/third_party/llvm-build/Release+Asserts/./bin/clang
https://github.com/aeubanks closed
https://github.com/llvm/llvm-project/pull/75542
___
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/75542
>From 884347b73d68e2d469b3903f248e72921434 Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Thu, 14 Dec 2023 15:41:31 -0800
Subject: [PATCH 1/3] [Instrumentation][X86] Limit setting large section flag
https://github.com/aeubanks edited
https://github.com/llvm/llvm-project/pull/75542
___
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/75542
___
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/75542
>From 884347b73d68e2d469b3903f248e72921434 Mon Sep 17 00:00:00 2001
From: Arthur Eubanks
Date: Thu, 14 Dec 2023 15:41:31 -0800
Subject: [PATCH 1/2] [Instrumentation][X86] Limit setting large section flag
aeubanks wrote:
Actually I'm going to go down the `Module::getCodeModel()` route. Right now I
think frontends adding module metadata for the code model is probably not
common, but we should aim for that. And this will in the short term still work
for Fuchsia without breaking API for other
https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/75542
In #74514 and #74778 we marked various instrumentation-added sections as
large. This causes an extra PT_LOAD segment if using the small code
model. Since people using the small code model presumably aren't
@@ -57,6 +57,16 @@ global variable or function should be in after translation.
let Heading = "section, __declspec(allocate)";
}
+def CodeModelDocs : Documentation {
+ let Category = DocCatVariable;
+ let Content = [{
+The ``model`` attribute allows you to use a different
aeubanks wrote:
is it too late to change the gcc attribute name?
https://github.com/llvm/llvm-project/pull/72078
___
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/71447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aeubanks wrote:
thanks!
https://github.com/llvm/llvm-project/pull/71447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 368 matches
Mail list logo
