@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20
@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20
https://github.com/dwblaikie approved this pull request.
SGTM
https://github.com/llvm/llvm-project/pull/75142
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie approved this pull request.
Sounds good to me, thanks!
https://github.com/llvm/llvm-project/pull/75022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Still seems like an unfortunate and subtle silent change in behavior to me. But
*shrug* if folks who own these features think it's fine, so be it.
https://github.com/llvm/llvm-project/pull/74809
___
cfe-commits mailing list
dwblaikie wrote:
> > Probably would be good to introduce the `-v1` version and require it first,
> > then eventually change the default - so people don't get a silent behavior
> > change? Even the existing users only using `*` and `.` need to change their
> > syntax to migrate to v2, right?
dwblaikie wrote:
Probably would be good to introduce the `-v1` version and require it first,
then eventually change the default - so people don't get a silent behavior
change? Even the existing users only using `*` and `.` need to change their
syntax to migrate to v2, right? They'll need to
dwblaikie wrote:
> To support access to such constants from LLDB we'll most likely have to have
> to make LLDB find the constants by looking at the containing class first.
Tangentially related to:
dwblaikie wrote:
I'd still like to know more about what other implementations do - see ongoing
discussion on the original issue.
https://github.com/llvm/llvm-project/pull/74419
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
dwblaikie wrote:
> > So what breakage is caused by the sorting failure?
>
> @dwblaikie This is not causing a breakage. It is just not working as designed
> because the sort function has been comparing `""` against `""` since commit
>
dwblaikie wrote:
> I.e., two `DIGlobalVariableExpression`s for the same `DIGlobalVariable`,
> which AFAICT would confuse `DwarfDebug` at the moment, which expects there to
> be a 1-to-1 mapping.
Would confuse `DwarfDebug` without your changes/this patch? Or only with this
patch?
(& hopefully
dwblaikie wrote:
> I did have a related RFC, but the
> [proposal](https://discourse.llvm.org/t/rfc-improving-clangs-middle-and-back-end-diagnostics/69261/16?u=nickdesaulniers)
> from @rnk is a yak shave that I don't intend to pursue.
I'd push on that a bit more. As I mentioned on the phab
dwblaikie wrote:
So what breakage is caused by the sorting failure? Can that behavior be tested
in some way to validate this change and ensure it doesn't regress in the future?
https://github.com/llvm/llvm-project/pull/73323
___
cfe-commits mailing
dwblaikie wrote:
> OK. I modified this PR in order to only make the changes that fix #73145 .
> Sorting will remain broken as it has been since 2021. I will provide another
> PR after this one gets merged.
Thanks, really appreciate your patience/understanding here - I know it's a bit
of a
https://github.com/dwblaikie approved this pull request.
Sounds reasonable to me, thanks!
https://github.com/llvm/llvm-project/pull/73146
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
dwblaikie wrote:
> Splitting it wouldn't help with bisect, as we would continue having a broken
> commit.
Not sure I understand - presumably this bug has existed for a while, separate
from the qsort issue? So fixing it separately seems good so that patches do one
thing clearly - makes it
Does this diagnostic have test coverage, could it be expanded to check the
spelling here? (mostly as a motivation to ensure this diagnostic is
actually tested... )
On Mon, Nov 20, 2023 at 3:04 AM via cfe-commits
wrote:
>
> Author: Utkarsh Saxena
> Date: 2023-11-20T12:04:32+01:00
> New Revision:
dwblaikie wrote:
> This commit also fixes commit
> https://github.com/llvm/llvm-project/commit/d3676d4b666ead794fc58bbc7e07aa406dcf487a
> that caused all headers to have NameAsWritten set to a 0-length string
> without adapting compareModuleHeaders() to the new field.
Sorry, I don't quite
dwblaikie wrote:
(part of the point is so that patches can be reverted as needed without having
to revert/reapply huge patches when they aren't actually dependent)
https://github.com/llvm/llvm-project/pull/73000
___
cfe-commits mailing list
dwblaikie wrote:
Generally when we split things up, they're separate reviews and separate
commits. fixups are for necessary changes that need to be applied atomically
(fixes to the base patch in a pull request, etc).
https://github.com/llvm/llvm-project/pull/73000
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/73000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2402,7 +2402,7 @@ void tools::checkAMDGPUCodeObjectVersion(const Driver ,
unsigned tools::getAMDGPUCodeObjectVersion(const Driver ,
const llvm::opt::ArgList ) {
- unsigned CodeObjVer = 4; // default
+ unsigned CodeObjVer = 5;
@@ -4708,12 +4708,12 @@ defm amdgpu_ieee : BoolOption<"m", "amdgpu-ieee",
NegFlag>, Group;
def mcode_object_version_EQ : Joined<["-"], "mcode-object-version=">,
Group,
- HelpText<"Specify code object ABI version. Defaults to 4. (AMDGPU only)">,
+ HelpText<"Specify code
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/71564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
I'm still really hesitant about this direction.
One starting concern: what happens if someone adds an overload, or other
interesting name resolution to the module? The downstream caller hasn't
textually changed, but it should be rebuilt because it should be calling a
dwblaikie wrote:
(patches like this should probably be broken up - test changes to the defaults
in lld and llvm for instance don't depend on the change to the clang driver
which is the only real semantic change in this patch, right? So probably only
change the semantics of clang, and the
dwblaikie wrote:
https://github.com/llvm/llvm-project/blob/abd85cd473afedf112bf00630a22382fee4a7853/llvm/lib/CodeGen/GlobalMerge.cpp#L531
- this is around where I think we'd get a global with a location and a
non-empty expression
https://github.com/llvm/llvm-project/pull/72730
dwblaikie wrote:
> My understanding was that the DIExpression parameter to
> DIGlobalVariableExpression was empty for global variables with locations. So
> the patch just encodes the constant into that expression if it's otherwise
> empty.
I think in theory it can be non-empty (see what
https://github.com/dwblaikie approved this pull request.
Looks plausible to me, thanks!
https://github.com/llvm/llvm-project/pull/71564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Hmm, I can't quite tell from the test case updates in the patch, at least at a
glance: How does this get encoded at the IR level? Do we end up with two
DIGlobalVariableExpressions? One with the constant value expresison, and one
that references the actual global variable? Or
@@ -0,0 +1,48 @@
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /Z7 -o %t.obj -- %s
dwblaikie wrote:
Generally clang tests don't test end-to-end. If the code change only affects
clang IR generation, the test should only test clang IR generation, not all the
@@ -0,0 +1,65 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-obj -fmodules -fimplicit-module-maps
-fmodules-cache-path=%t %t/main.cpp -o %t/main.o
+
+//--- V.h
+#ifndef V_H
+#define V_H
+
+class A {
+public:
+ constexpr
https://github.com/dwblaikie approved this pull request.
SGTM
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Might be worth cconsidering the points in "Contributing Extensions to Clang"
here: https://clang.llvm.org/get_involved.html
It'd be great if there were some numbers/metrics associated with the benefit,
ideally on some open source/commonly accessible codebase.
On Mon, Nov 13, 2023 at 4:28 AM Aaron Ballman
wrote:
> On Sun, Nov 12, 2023 at 11:42 PM David Blaikie wrote:
> >
> > Any chance this could/should reference the length by name, rather than
> by casts and pointer math? (so it's resilient to at least some changes to
> StringLiteral/StringRef?) Or
Any chance this could/should reference the length by name, rather than by
casts and pointer math? (so it's resilient to at least some changes to
StringLiteral/StringRef?) Or is this the preferred way to write Natvis
visualizers, so they're resilient to missing debug info or something?
On Sun, Nov
dwblaikie wrote:
The words probably don't need to be short.
Interface BMI
Implementation BMI
Seem like fine, accurate terms. I guess we could say "BMInterface" and
"BMImplementation" but probably best to jus tgloss over "I" being "interface"
and have "interface BMI" and "implementation BMI"
dwblaikie wrote:
We probably (pretty sure) don't want to add a virtual dtor to SmallVector -
that'd add a vtable pointer, increasing the size in ways that are probably
unacceptable given the pervasive use of the data structure.
We should make the Impl dtor protected so it can't be
dwblaikie wrote:
Please don't commit changes that have been sent for review, but have not been
reviewed.
https://github.com/llvm/llvm-project/pull/71031
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
dwblaikie wrote:
FWIW, we saw failures at Google (where, to the best of my knowledge, we aren't
using named modules at all) that look like this:
```
error: '#include ' attaches the declarations to the named module
'.get', which is not usually intended; consider moving that directive before
dwblaikie wrote:
> 2) always put DW_AT_const_value in DW_TAG_member.
My understanding is that this is not possible. Dependent initializer
expressions can't be evaluated in all cases - we're only allowed to evaluate
them in the places the language allows us to, otherwise we might produce the
dwblaikie wrote:
> That's true, if defined in a header, we'll emit a DW_TAG_variable for the
> constant in each compile unit the header is included in. GCC does do the
> right thing and only emit the definition DIE in a single CU. We should
> probably do the same. Though not sure at which
https://github.com/dwblaikie approved this pull request.
Few minor issues, but looks good to me.
(you metnioned somewhere an lldb issue I think with this patch when the value
is removed from the static member declaration inside the class? If that's a
problem - probably hold off on committing
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int
@@ -5883,6 +5907,18 @@ void CGDebugInfo::finalize() {
DBuilder.replaceTemporary(std::move(FwdDecl), cast(Repl));
}
+ for (auto const *VD : StaticDataMemberDefinitionsToEmit) {
+assert(VD->isStaticDataMember());
+
+if (auto It = DeclCache.find(VD); It !=
@@ -67,15 +67,15 @@ int C::a = 4;
// CHECK-NOT:size:
// CHECK-NOT:align:
// CHECK-NOT:offset:
-// CHECK-SAME: flags: DIFlagStaticMember,
-// CHECK-SAME: extraData: i1 true)
+// CHECK-SAME: flags:
https://github.com/dwblaikie approved this pull request.
Looks great - thanks!
https://github.com/llvm/llvm-project/pull/70674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
size report sounds generally OK - but there's a bunch of what look like
unrelated or strange results in there, perhaps they weren't compared at exactly
the same version? (like why did the apple_names size go down? How did the .text
and .debuG_line size change at all? )
dwblaikie wrote:
> > > Should not we remove constant initializer from the type definition if we
> > > have a DW_TAG_variable with a DW_AT_const_value now?
> >
> >
> > Yep, +1 to this. This is where the type normalization benefit would come
> > from - no longer having this const value on the
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
dwblaikie wrote:
> Summing the size of all *.o files in my local debug Clang build increased by
> 0.7% with this patch
That's a bit significant. Any chance you could get a per-section
breakdown/growth on that? (& exact flags - is this with compressed debug info,
for instance? Or not?) I use
dwblaikie wrote:
> Should not we remove constant initializer from the type definition if we have
> a DW_TAG_variable with a DW_AT_const_value now?
Yep, +1 to this. This is where the type normalization benefit would come from -
no longer having this const value on the member declaration, but
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int
@@ -0,0 +1,43 @@
+; RUN: llvm-as < %s -o %t0
+; RUN: llvm-dis %t0 -o - | FileCheck %s
+
dwblaikie wrote:
might be worth a comment describing the purpose of this test (some info from
the commit message, probably)
https://github.com/llvm/llvm-project/pull/68986
@@ -731,6 +731,29 @@ class MetadataLoader::MetadataLoaderImpl {
upgradeCULocals();
}
+ void cloneLocalTypes() {
+for (int I = MetadataList.size() - 1; I >= 0; --I) {
dwblaikie wrote:
any particular reason this iterates in reverse? Probably worth a
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/68986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/68986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation , const JobAction
,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation , const JobAction
,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation , const JobAction
,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+
https://github.com/dwblaikie approved this pull request.
Some minor comments but generally looks good to me.
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def
dwblaikie wrote:
> ```c++
> struct A {
> short a1;
> short a2;
> };
>
> struct B {
> [[clang::preferred_type(A)]] unsigned b1 : 32 = 0x000F'000C;
> };
>
> int main()
> {
> B b;
> return b.b1;
> }
> ```
An example where the layout doesn't match the normal struct layout might be
dwblaikie wrote:
> > FWIW, I think we also saw, internally at Google, some significant and
> > surprising (growth in sections, like .debug_loclists and
> > .debug_gnu_pubnames/types) that were a bit surprising/not what I'd have
> > expected of the original committed/reverted patch.
> > Could
dwblaikie wrote:
> > I still support disabling delayed template parsing by default in all
> > configurations. Ultimately, this feature is a source of bugs, and we should
> > start the clock on its deprecation and removal. This, of course, involves
> > real work, and I haven't allocated any
https://github.com/dwblaikie approved this pull request.
Looks good.
I wonder how this happened in the first place - that the author of the
diagnostic was already adding the 3rd parameter into the arguments but there
was no `%2` in the diagnostic text/template...
It'd be great if we had
dwblaikie wrote:
Does MSVC have the delayed template parsing effects when using modules? If not,
perhaps we should just disable the flag/not allow it to be composed together?
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing
@@ -62,7 +62,7 @@ def err_ast_file_out_of_date : Error<
"%select{PCH|module|AST}0 file '%1' is out of date and "
"needs to be rebuilt%select{|: %3}2">, DefaultFatal;
def err_ast_file_invalid : Error<
- "file '%1' is not a valid precompiled %select{PCH|module|AST}0 file">,
dwblaikie wrote:
> Wouldn't it be better to go the other way around? i.e. have a
> `[[clang::compressed_bitfield]]` (or whatever) which influences the ABI, so
> it's possible to do stuff like
>
> ```c++
> [[clang::compressed_bitfield]] bool IsSomething : 1;
> [[clang::compressed_bitfield]]
dwblaikie wrote:
Seems a bit unfortunate/bit of a heavyweight workaround - but I don't
fundamentally object if @AaronBallman or co are OK with the new attribute for
this.
https://github.com/llvm/llvm-project/pull/69104
___
cfe-commits mailing list
dwblaikie wrote:
> This is useful when user is forced to use the same type for all bitfields in
> a class to get better [layout](https://godbolt.org/z/ovWqzqv9x) and
> [codegen](https://godbolt.org/z/bdoqvz9e6) from MSVC
Does this issue not apply to other platforms? (I didn't think you could
dwblaikie wrote:
FWIW, I think we also saw, internally at Google, some significant and
surprising (growth in sections, like .debug_loclists and
.debug_gnu_pubnames/types) that were a bit surprising/not what I'd have
expected of the original committed/reverted patch.
Could you run a clang
@@ -2028,6 +2030,8 @@ example:
This attribute suggests that optimization passes and code generator passes
should make choices that try to preserve debug info without significantly
degrading runtime performance.
+This attribute is incompatible with the
@@ -1085,6 +1085,7 @@ The integer codes are mapped to well-known attributes as
follows.
* code 77: ``elementtype``
* code 78: ``disable_sanitizer_instrumentation``
* code 79: ``nosanitize_bounds``
+* code 88: ``optdebug``
dwblaikie wrote:
This could/should
https://github.com/dwblaikie approved this pull request.
looks good - a few bits should be committed separately from this change, so
please do those first and then commit this change
https://github.com/llvm/llvm-project/pull/66632
___
cfe-commits
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/66632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,158 @@
+//===- raw_ostream_proxy.h - Proxies for raw output streams -*- 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/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/68501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
*shrug* I guess it's OK.
https://github.com/llvm/llvm-project/pull/68501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
This doesn't seem all that useful/important to me - a user can move the body of
the function into an implementation unit rather than putting it in the
interface unit and marking it noinline, right? This is the same recommendation
we'd make if someone wrote a complex function
@@ -106,14 +107,71 @@ static void findReturnsToZap(Function ,
}
}
-static bool runIPSCCP(
-Module , const DataLayout , FunctionAnalysisManager *FAM,
-std::function GetTLI,
-std::function GetTTI,
-std::function GetAC,
-std::function GetDT,
-
@@ -106,14 +107,71 @@ static void findReturnsToZap(Function ,
}
}
-static bool runIPSCCP(
-Module , const DataLayout , FunctionAnalysisManager *FAM,
-std::function GetTLI,
-std::function GetTTI,
-std::function GetAC,
-std::function GetDT,
-
@@ -106,14 +107,71 @@ static void findReturnsToZap(Function ,
}
}
-static bool runIPSCCP(
-Module , const DataLayout , FunctionAnalysisManager *FAM,
-std::function GetTLI,
-std::function GetTTI,
-std::function GetAC,
-std::function GetDT,
-
@@ -106,14 +107,71 @@ static void findReturnsToZap(Function ,
}
}
-static bool runIPSCCP(
-Module , const DataLayout , FunctionAnalysisManager *FAM,
-std::function GetTLI,
-std::function GetTTI,
-std::function GetAC,
-std::function GetDT,
-
dwblaikie wrote:
> This only affects builds with GCC.
My understanding was that we basically only cared about performance of clang on
clang - that we expect people who want an efficient clang to bootstrap?
Could `always_inline` the function, but those sort of annotations would get out
of
Carlos =?utf-8?q?Gálvez?= ,
Carlos =?utf-8?q?Gálvez?=
Message-ID:
In-Reply-To:
dwblaikie wrote:
> It seems checks are broken on trunk, I see commits merged with failing
> pre-merge tests. They seem to be unrelated to this patch though.
>
> Is there anything else you'd like fixed before
https://github.com/dwblaikie approved this pull request.
Awesome - love a good readability improvement. Thanks!
https://github.com/llvm/llvm-project/pull/67900
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
dwblaikie wrote:
Oh, no worries at all. LLVM 's still figuring out this whole GitHub transition
anyway. I mention it only for future reference and because it might help
reviewers/you if comments are getting missplaced/there's trouble tracking
unaddressed feedback, etc.
Thanks for sticking
dwblaikie wrote:
(aside: I was confused why there was only one commit in this PR, since there'd
been so many updates to it - but I see they've been force pushed, which my
vague understanding is that force pushing can complicate tracking previous
comments and the LLVM convention is not to do
@@ -1245,6 +1245,27 @@ void Sema::ActOnEndOfTranslationUnit() {
}
}
+// Now we can decide whether the modules we're building need an
initializer.
+if (Module *CurrentModule = getCurrentModule();
+CurrentModule &&
@@ -2325,6 +2325,7 @@ void
CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
B.addAttribute(llvm::Attribute::Naked);
// OptimizeNone wins over OptimizeForSize and MinSize.
+F->removeFnAttr(llvm::Attribute::OptimizeForDebugging);
@@ -0,0 +1,301 @@
+//===- llvm/ADT/PagedVector.h - 'Lazyly allocated' vectors *- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -0,0 +1,301 @@
+//===- llvm/ADT/PagedVector.h - 'Lazyly allocated' vectors *- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -7944,9 +7944,13 @@ void ASTReader::PrintStats() {
std::fprintf(stderr, "*** AST File Statistics:\n");
unsigned NumTypesLoaded =
- TypesLoaded.size() - llvm::count(TypesLoaded, QualType());
+ TypesLoaded.size() - std::count(TypesLoaded.materialisedBegin(),
@@ -0,0 +1,301 @@
+//===- llvm/ADT/PagedVector.h - 'Lazyly allocated' vectors *- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -0,0 +1,301 @@
+//===- llvm/ADT/PagedVector.h - 'Lazyly allocated' vectors *- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
201 - 300 of 1342 matches
Mail list logo
