[clang] [DebugInfo] Init DwarfVersion of MCOptions like the other. (PR #146666)

2025-07-02 Thread David Blaikie via cfe-commits
dwblaikie wrote: I guess this would be visible when using clang to compile some assembly code and requesting debug info of a specific version? Is that the case? Could you add a test case showing that this has a/the desired effect? https://github.com/llvm/llvm-project/pull/14 __

[clang] [DebugInfo] Produce debuginfo for nested types when the outer type is [[clang::standalone_debug]] (PR #146175)

2025-06-30 Thread David Blaikie via cfe-commits
dwblaikie wrote: I don't think this is the right direction. standalone_debug shouldn't affect truly unused types - I don't think nested or unnested unused types should be treated the same in this regard (because they are treated the same in every other regard, I think) Got a particular exampl

[clang] [llvm] [STLForwardCompat] Implement llvm::type_identity (PR #146390)

2025-06-30 Thread David Blaikie via cfe-commits
dwblaikie wrote: unit test would be nice (just in the form of a static_assert, probably) https://github.com/llvm/llvm-project/pull/146390 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[clang] [llvm] [mlir] [ADT] Deprecate MutableArrayRef(std::nullopt) (PR #146113)

2025-06-27 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/146113 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-25 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie closed https://github.com/llvm/llvm-project/pull/141106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-24 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie edited https://github.com/llvm/llvm-project/pull/141106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-24 Thread David Blaikie via cfe-commits
@@ -1301,4 +1301,33 @@ TEST(DIBuilder, CompositeTypes) { EXPECT_EQ(Enum->getTag(), dwarf::DW_TAG_enumeration_type); } +TEST(DIBuilder, DynamicOffsetAndSize) { + LLVMContext Ctx; + std::unique_ptr M(new Module("MyModule", Ctx)); dwblaikie wrote: Prefer `st

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-24 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. Yeah, let's just go with this as a single patch. Looking closer, in retrospect/for next time, perhaps this could've been a few smaller patches (I guess the strtuct, member, and bit field member are all separate except that they depend on

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-17 Thread David Blaikie via cfe-commits
@@ -1525,15 +1525,24 @@ Error MetadataLoader::MetadataLoaderImpl::parseOneMetadata( if (Record.size() < 6 || Record.size() > 8) return error("Invalid record"); -IsDistinct = Record[0]; +IsDistinct = Record[0] & 1; +bool SizeIsMetadata = Record[0] & 2;

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-17 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/141106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-17 Thread David Blaikie via cfe-commits
@@ -4822,6 +4822,35 @@ struct MDSignedOrMDField : MDEitherFieldImpl { } }; +struct MDUnsignedOrMDField : MDEitherFieldImpl { + MDUnsignedOrMDField(uint64_t Default = 0, bool AllowNull = true) + : ImplTy(MDUnsignedField(Default), MDField(AllowNull)) {} + + MDUnsignedO

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-17 Thread David Blaikie via cfe-commits
@@ -834,8 +834,8 @@ llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) { auto *ISATy = DBuilder.createPointerType(ClassTy, Size); ObjTy = DBuilder.createStructType(TheCU, "objc_object", TheCU->getFile(), 0, - 0, 0, llvm:

[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #142166)

2025-06-17 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > So maybe the solution is as simple as removing the "unique" from > > DISubprogram definitions, and the existing infrastructure will handle it? > > (maybe have to expand it to allow it to work for things with > > DISPFlagDefinition... ) > > If I understand the idea behind

[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #142166)

2025-06-17 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > How does this work for LTO? (we'd want all inlined instances to refer to a > > singular abstract definition) Yeah, looks like that's broken (the abstract > > origins are not shared - they're duplicated in every translation unit). > > But the notion of "abstract" subprogram

[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #142166)

2025-06-17 Thread David Blaikie via cfe-commits
dwblaikie wrote: > (Transparency, I wrote some of the code in the PR so dunno if I should review > it,) > > > I /think/ function-local types need to go in definitions - in /abstract/ > > definitions if they exist (not in the inlined instances or concrete out of > > line instances). > > I thi

[clang] [llvm] Non constant size and offset in DWARF (PR #141106)

2025-06-16 Thread David Blaikie via cfe-commits
@@ -834,8 +834,8 @@ llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) { auto *ISATy = DBuilder.createPointerType(ClassTy, Size); ObjTy = DBuilder.createStructType(TheCU, "objc_object", TheCU->getFile(), 0, - 0, 0, llvm:

[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #142166)

2025-06-06 Thread David Blaikie via cfe-commits
dwblaikie wrote: I know this scoping local non-instance specific entities work has/continues to be a long, arduous, journey... but I'm not sure this particular step is right. I /think/ function-local types need to go in definitions - in /abstract/ definitions if they exist (not in the inlined

[clang] [clang][python][test] Move python binding tests to lit framework (PR #142948)

2025-06-06 Thread David Blaikie via cfe-commits
@@ -0,0 +1,22 @@ +def is_libclang_loadable(): +try: +sys.path.append(os.path.join(config.clang_src_dir, "bindings/python")) +from clang.cindex import Config +conf = Config() +Config.set_library_path(config.clang_lib_dir) +conf.lib +

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-06-06 Thread David Blaikie via cfe-commits
dwblaikie wrote: > I think this can be solved by setting the line number to the line number of, > e.g., the `class` / `struct` keyword or the line number of the class name, or > whatever is easily available Possibly, though I'm not sure if we should. We don't put a line number on an implicit

[clang] [clang][python][test] Move python binding tests to lit framework (PR #142948)

2025-06-05 Thread David Blaikie via cfe-commits
@@ -0,0 +1,22 @@ +def is_libclang_loadable(): +try: +sys.path.append(os.path.join(config.clang_src_dir, "bindings/python")) +from clang.cindex import Config +conf = Config() +Config.set_library_path(config.clang_lib_dir) +conf.lib +

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-05-22 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/130255 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [llvm][DebugInfo][clang] Finalize all declaration subprograms in DIBuilder::finalize() (PR #139914)

2025-05-21 Thread David Blaikie via cfe-commits
dwblaikie wrote: yeah, can't say I have any recollection of why function declaration would be in a "retained types" list - probably incidental/not especially intentional (we didn't make declarations for functions, except member functions, until "recently" when call site debug info was added).

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-05-20 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie commented: Could you remove the LLVM tests? They don't add coverage since tnhis isn't an LLVM feature - as far as LLVM is concerned, this is another static member variable like any other. Why do some of the test cases use distinct input files/headers? I'd have tho

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-05-15 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie commented: We can skip the llvm testing here, I think - there are no LLVM changes to test. (as far as LLVM is concerned, this is just another static member variable) Got measurements on debug info size growth or any other metrics we should be considering? https://

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-05-12 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > My intent (haven't checked the patch) is that it'd be modeled as a static > > member variable - so there'd be a declaration in the class, but a > > definition DIE outside the class that'd be indexed by gdb OK, I'd have > > thought? (it'd go in .debug_names, and gdb_index,

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-05-12 Thread David Blaikie via cfe-commits
dwblaikie wrote: (I'm open to being overruled by other folks/perspectives if the straight up global variable is preferred - other folks who are in support of that?) https://github.com/llvm/llvm-project/pull/130255 ___ cfe-commits mailing list cfe-com

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-05-12 Thread David Blaikie via cfe-commits
dwblaikie wrote: Ah, yeah, I see the example from https://github.com/llvm/llvm-project/pull/130255#issuecomment-2866460040 isn't consistent with what I had in mind (in the example there the member DIE is a definition - I don't think many consumers will be ready to handle that, since it's not

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-05-12 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > Uploaded a patch that eliminates the global variable and it moves the > > vtable information into the static member; in that way, a consumer always > > will have access to the vtable information, just by having the object > > instance or the object definition. > > IIUC th

[clang] Emit nested unused enum types with -fno-eliminate-unused-debug-types (PR #137818)

2025-05-12 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/137818 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [DLCov 2/5] Implement DebugLoc coverage tracking (PR #107279)

2025-04-23 Thread David Blaikie via cfe-commits
@@ -169,6 +169,47 @@ See the discussion in the section about :ref:`merging locations` for examples of when the rule for dropping locations applies. +.. _NewInstLocations: + +Setting locations for new instructions +-- + +Whenever a new instru

[clang] [llvm] [DLCov 2/5] Implement DebugLoc coverage tracking (PR #107279)

2025-04-23 Thread David Blaikie via cfe-commits
@@ -169,6 +169,47 @@ See the discussion in the section about :ref:`merging locations` for examples of when the rule for dropping locations applies. +.. _NewInstLocations: + +Setting locations for new instructions +-- + +Whenever a new instru

[clang] [CodeGen] Don't include CGDebugInfo.h in CodeGenFunction.h (NFC) (PR #134100)

2025-04-02 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/134100 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-03-31 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > Removing the vtable global variable and moving the "location info" into the > > static within the class, will work for the SCE debugger. > > I was thinking about this last night and wondering if the vtable will appear > as a class member even if the class is local to a fun

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-03-25 Thread David Blaikie via cfe-commits
dwblaikie wrote: > FYI: There is already VTable support in our lldb::SBValue class and it is > part of the public API in LLDB and doesn't require any of this: > ... > Doesn't require any debug info. Does this/can this be used to determine the type of an object that points to that vtable, thoug

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-03-24 Thread David Blaikie via cfe-commits
dwblaikie wrote: > The link from the class to the specific vtable even seems mildly incorrect, > in that during object construction the vtable will go through several > different values, not just one. Not sure I follow this - the object is only of the type, in some sense, when it is pointing

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-03-17 Thread David Blaikie via cfe-commits
dwblaikie wrote: > It would be better if we could go from the vtable pointer straight to the > right type DIE, but I don't think we can do that without inventing a new sort > of an accelerator table (which I guess we don't have an appetite for). yeah, data address lookup (as opposed to code ad

[clang] [llvm] Add support for template as type parameter (PR #127654)

2025-03-12 Thread David Blaikie via cfe-commits
dwblaikie wrote: > Could you please take a look at the attached DWARF and let me know your > concerns with the implementation? Sure - I see the effect, but I still think it's probably not worthwhile due to the limited capacity, inconsistency (due to that limited expressiveness) between direct

[clang] [llvm] Add support for template as type parameter (PR #127654)

2025-03-11 Thread David Blaikie via cfe-commits
dwblaikie wrote: > Are you suggesting that for the implementation to be considered as complete, > both v1 and v2 should have the same type information? I.e "v1" type should > point to 0x48 instead of 0x6d? As per my understanding based on the DWARF > output below, the type for "trait::type"(0x

[clang] [Docs] Explain how to propose an extension in Clang (PR #130803)

2025-03-11 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. Sounds good to me - thanks for writing it up! (could wait for other folks to chime in too, but seems pretty harmless to launch/iterate/etc) https://github.com/llvm/llvm-project/pull/130803 ___ c

[clang] [llvm] Add support for template as type parameter (PR #127654)

2025-03-11 Thread David Blaikie via cfe-commits
dwblaikie wrote: > I am not sure that I understand your concern completely. Consider the > following DWARF output based on my implementation. How would you say "v1" > should be represented ideally? > ``` > 0x0042: DW_TAG_structure_type > DW_AT_calling_convention (DW_CC_pass_by_value) > DW_A

[clang] [llvm] Add support for template as type parameter (PR #127654)

2025-03-07 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > Mostly I worry it won't be terribly complete, because it can't work through > > situations, like this: > > ``` > > template > > struct trait { > > using type = T; > > }; > > template > > struct other { > > trait::type v1; > > T v2; > > }; > > ``` > > In this case, v2

[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)

2025-03-07 Thread David Blaikie via cfe-commits
dwblaikie wrote: I wouldn't mind a few more details here on the motivation. > This new symbol will allow a debugger to easily associate classes with the > physical location of their VTables using only the DWARF information. What sort of features are you picturing building with this? The DWAR

[clang] [llvm] Add support for template as type parameter (PR #127654)

2025-02-21 Thread David Blaikie via cfe-commits
dwblaikie wrote: > For template classes with type parameters, the information of which member > variables are of a "templated type" is lost. The debugger cannot > differentiate between "templated" types and "hardcoded" types. This is > because both types have the same debug information, so the

[clang] [clang-tools-extra] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > > I don't quite follow the motivation for this, can you expand on this in > > > the description please? Right now this seems unnecessary for the changes > > > I can see in MLIR for example. > > > > > > The linked bug seems to explain it, I think? It seems to be the usual

[clang] [clang-tools-extra] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

2025-02-07 Thread David Blaikie via cfe-commits
dwblaikie wrote: > I don't quite follow the motivation for this, can you expand on this in the > description please? Right now this seems unnecessary for the changes I can > see in MLIR for example. The linked bug seems to explain it, I think? It seems to be the usual "if something isn't/does

[clang] [StrTable] Fix modules build and clean up stale files (PR #125979)

2025-02-06 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/125979 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Force AttributedStmtClass to not be scope parents (PR #125370)

2025-02-03 Thread David Blaikie via cfe-commits
dwblaikie wrote: Could you add a test case - check in clang/test to see if other tests for the diagnostic text in the original bug, and add a test case for that nearby (maybe the same file the diagnostic is already tested in)? https://github.com/llvm/llvm-project/pull/125370 __

[clang] [llvm] [WIP][clang][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (PR #124752)

2025-02-03 Thread David Blaikie via cfe-commits
dwblaikie wrote: Is my thing about the ctor understanding correct, and it's that the ctor exists theoretically/abstractly, but not in the AST or in the generated IR/DWARF? Could it be added/would that be sufficient? But, yeah, probably fine to just add the attribute, since that's the real fea

[clang] [clang-cl]: generate debug info when `novtable` is specified (PR #124643)

2025-01-28 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie closed https://github.com/llvm/llvm-project/pull/124643 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-cl]: generate debug info when `novtable` is specified (PR #124643)

2025-01-28 Thread David Blaikie via cfe-commits
dwblaikie wrote: Do you have commit access, or need someone to merge this on your behalf? https://github.com/llvm/llvm-project/pull/124643 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi

[clang] [llvm] [WIP][clang][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (PR #124752)

2025-01-28 Thread David Blaikie via cfe-commits
dwblaikie wrote: (hmm, can't use the foundation library on godbolt/compiler explorer) Can you show a small example of the code you're interested in and the DWARF it produces? The documentation I can find seems to suggest that the extensible enums have ctors that take the underlying integer type

[clang] [clang-cl]: generate debug info when `novtable` is specified (PR #124643)

2025-01-27 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. Looks great - thanks! https://github.com/llvm/llvm-project/pull/124643 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][DebugInfo] Emit DW_AT_object_pointer on function declarations with explicit `this` (PR #122928)

2025-01-23 Thread David Blaikie via cfe-commits
dwblaikie wrote: yeah, I was going to say - thought we carved out part (the debug info part, maybe some other things - ORC?) of the C API as unstable, so I'm OK continuing with that (lack of) guarantee... https://github.com/llvm/llvm-project/pull/122928

[clang] [llvm] Generate `DW_AT_RUST_short_backtrace` attributes for `DISubprogram` nodes (PR #123683)

2025-01-21 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > For instance, the StartFrame/EndFrame feature, if I'm understanding it > > correctly, seems like maybe it could be skipped if we're emitting DWARF (& > > instead the skip attribute could be placed on all the calls between > > StartFrame and EndFrame?). > > does [#123683

[clang] [llvm] [StrTable] Switch diag group names to `llvm::StringTable` (PR #123302)

2025-01-17 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. Generally looks fine to me - given the central nature of the data structure, wouldn't mind a second/more authoritative set of eyes if someone has time. You mention the performance tradeoff of pascal strings v null terminated ones doesn't

[clang] [llvm] [StrTable] Switch diag group names to `llvm::StringTable` (PR #123302)

2025-01-17 Thread David Blaikie via cfe-commits
@@ -51,6 +53,14 @@ class StringTable { constexpr Offset() = default; constexpr Offset(unsigned Value) : Value(Value) {} +constexpr bool operator==(const Offset &RHS) const { dwblaikie wrote: Minor convention, but prefer non-member (can still be de

[clang] [llvm] [StrTable] Switch diag group names to `llvm::StringTable` (PR #123302)

2025-01-17 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie edited https://github.com/llvm/llvm-project/pull/123302 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][DebugInfo] Emit DW_AT_object_pointer on function declarations with explicit `this` (PR #122928)

2025-01-17 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. Looks OK to me. https://github.com/llvm/llvm-project/pull/122928 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 504dd57 - DebugInfo: Avoid emitting null members for nodebug nested typedefs

2025-01-15 Thread David Blaikie via cfe-commits
Author: David Blaikie Date: 2025-01-15T23:20:40Z New Revision: 504dd577675e8c85cdc8525990a7c8b517a38a89 URL: https://github.com/llvm/llvm-project/commit/504dd577675e8c85cdc8525990a7c8b517a38a89 DIFF: https://github.com/llvm/llvm-project/commit/504dd577675e8c85cdc8525990a7c8b517a38a89.diff LOG:

[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)

2025-01-13 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > Just that the last bit of performance > > Maybe we're talking about different situations; I may have missed some > context in the discussion of this PR. I didn't see this as being about the > last bit of performance. It sounded like this was going to knowingly > introduce

[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)

2025-01-13 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > > Anyway, my main point was that there are people who care about > > > performance on Windows, so please don't treat it as a second-class > > > citizen. > > > > > > Yeah, I don't want to treat folks on Windows as second class citizens by > > any means - but I wouldn't mi

[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)

2025-01-13 Thread David Blaikie via cfe-commits
dwblaikie wrote: > Anyway, my main point was that there are people who care about performance on > Windows, so please don't treat it as a second-class citizen. Yeah, I don't want to treat folks on Windows as second class citizens by any means - but I wouldn't mind/hope we can treat folks who c

[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)

2025-01-10 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > Do we care about performance on MSVC ? > > Just responding to this point (although I accept it's moot in the current > context): yes we care about performance when building with MSVC - our > downstream toolchain is hosted on Windows. I'm sure we're not the only > Windows

[clang] Allow packing fields into tail padding of record fields (PR #122197)

2025-01-08 Thread David Blaikie via cfe-commits
@@ -803,10 +804,16 @@ bool ConstStructBuilder::Build(const InitListExpr *ILE, bool AllowOverwrite) { if (!AppendField(Field, Layout.getFieldOffset(FieldNo), EltInit, AllowOverwrite)) return false; - // After emitting a non-empty field

[clang] Allow packing fields into tail padding of record fields (PR #122197)

2025-01-08 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie commented: Thanks! Looks plausible to me, would be great to get @Michael137's take on it, since he's been looking at this sort of thing a fair bit lately. https://github.com/llvm/llvm-project/pull/122197 ___ cfe-commits ma

[clang] Allow packing fields into tail padding of record fields (PR #122197)

2025-01-08 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie edited https://github.com/llvm/llvm-project/pull/122197 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

2025-01-08 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/11 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Updating Debug Info generation for 'this' (PR #119445)

2024-12-17 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/119445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #119001)

2024-12-13 Thread David Blaikie via cfe-commits
dwblaikie wrote: yeah, I worry this feels all a bit vague (that some things "suggest" other things, that root problems "seem to be" (& some fairly broad descriptions of what they seem to be) - not to nitpick your language, and I appreciate the clarity of the uncertainty, to be sure - but the u

[clang] [NFC] Updating Debug Info generation for 'this' (PR #119445)

2024-12-10 Thread David Blaikie via cfe-commits
dwblaikie wrote: any chance you could A/B test this on a bootstrap of clang, for instance? To help validate that this really is NFC/dead code? https://github.com/llvm/llvm-project/pull/119445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org htt

[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #119001)

2024-12-10 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > Maybe it's too big/complex a problem to try to think about, and incremental > > development should overrule here - but may be worth thinking about? > > Urgh. I'll admit that I hadn't thought that far ahead, I just wanted to get > the patch-series going again now that the r

[clang] [HLSL] Fix debug info generation for RWBuffer types (PR #119041)

2024-12-09 Thread David Blaikie via cfe-commits
@@ -2021,28 +2021,10 @@ llvm::DISubroutineType *CGDebugInfo::getOrCreateInstanceMethodType( // ThisPtr may be null if the member function has an explicit 'this' // parameter. if (!ThisPtr.isNull()) { -const CXXRecordDecl *RD = ThisPtr->getPointeeCXXRecordDecl(); -

[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #119001)

2024-12-09 Thread David Blaikie via cfe-commits
dwblaikie wrote: No idea if this sufficiently overlaps with, or is orthogonal to the following, but: Currently we don't scope function-local types into the appropriate scope inside a function. It seems like associating types with their declaration may make this harder to address - how would w

[clang] Switch builtin strings to use string tables (PR #118734)

2024-12-05 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. This looks fine to me - though given the broad impact (to every target in clang) maybe @AaronBallman wants to weigh in. If you wanted to front-load the things like `getRecord(ID).Attributes` -> `getAttributesString(ID)` those things coul

[clang] [Clang] Enable -fextend-lifetimes at -Og (PR #118026)

2024-12-04 Thread David Blaikie via cfe-commits
@@ -1834,6 +1834,14 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions &Opts, ArgList &Args, Opts.setInlining(CodeGenOptions::NormalInlining); } + // If we have specified -Og and have not explicitly set -fno-extend-lifetimes, + // then default to -fextend-li

[clang] [Clang] Add fake use emission to Clang with -fextend-lifetimes (PR #110102)

2024-12-04 Thread David Blaikie via cfe-commits
@@ -1353,6 +1353,19 @@ void CodeGenFunction::EmitLifetimeEnd(llvm::Value *Size, llvm::Value *Addr) { C->setDoesNotThrow(); } +void CodeGenFunction::EmitFakeUse(Address Addr) { + // We do not emit a fake use if we want to apply optnone to this function, + // even if we mig

[clang] [Clang] Add fake use emission to Clang with -fextend-lifetimes (PR #110102)

2024-12-03 Thread David Blaikie via cfe-commits
@@ -1353,6 +1353,19 @@ void CodeGenFunction::EmitLifetimeEnd(llvm::Value *Size, llvm::Value *Addr) { C->setDoesNotThrow(); } +void CodeGenFunction::EmitFakeUse(Address Addr) { + // We do not emit a fake use if we want to apply optnone to this function, + // even if we mig

[clang] [clang][codegen] Mention the invariant that LLVM demangler should be … (PR #117346)

2024-11-25 Thread David Blaikie via cfe-commits
dwblaikie wrote: (please don't merge PRs that haven't been approved, that's against LLVM practices/policies ( https://llvm.org/docs/CodeReview.html#code-review-workflow ), unless they weren't intended for pre-commit review in the first place (if they were only meant for presubmit checks)) htt

[clang] [clang-tools-extra] [flang] [lld] [lldb] [llvm] [NFC] Rename Option parsing related files from OptXYZ -> OptionXYZ (PR #110692)

2024-10-08 Thread David Blaikie via cfe-commits
dwblaikie wrote: Yeah, I think given how wide the change is and the speculative nature of the harm - probably best to abandon this for now. We can pick it up again if more folks speak up/more evidence is presented that it's problematic. https://github.com/llvm/llvm-project/pull/110692

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

2024-10-03 Thread David Blaikie via cfe-commits
@@ -211,6 +211,16 @@ New Compiler Flags only for thread-local variables, and none (which corresponds to the existing ``-fno-c++-static-destructors`` flag) skips all static destructors registration. +- The ``-fextend-lifetimes`` and ``-fextend-this-ptr`` flags have been ad

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

2024-10-03 Thread David Blaikie via cfe-commits
@@ -0,0 +1,12 @@ +// RUN: %clang_cc1 %s -emit-llvm -O2 -fextend-lifetimes -o - | FileCheck --check-prefixes=CHECK-ALL,CHECK-O2 %s +// RUN: %clang_cc1 %s -emit-llvm -O0 -fextend-lifetimes -o - | FileCheck --check-prefixes=CHECK-ALL,CHECK-O0 %s + +// Checks that we emit the functi

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

2024-10-03 Thread David Blaikie via cfe-commits
@@ -2217,6 +2217,11 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions &Opts, ArgList &Args, Args.getAllArgValues(OPT_fsanitize_trap_EQ), Diags, Opts.SanitizeTrap); + Opts.ExtendThisPtr = + Opts.OptimizationLevel > 0

[clang] [clang][DebugInfo] Revert to printing canonical typenames for template aliases (PR #110767)

2024-10-02 Thread David Blaikie via cfe-commits
dwblaikie wrote: Thanks @jimingham - yeah, that makes sense. My original argument for being OK with the de-canonicalization of typedefs was that they aren't load bearing anyway. But if lldb puts load on them, that assumption doesn't hold. Yeah, could check for angles or template parameter DIEs

[clang] [clang][DebugInfo] Revert to printing canonical typenames for template aliases (PR #110767)

2024-10-02 Thread David Blaikie via cfe-commits
dwblaikie wrote: Not quite sure how we get to caching and template specializations and pretty printers. If we're still producing the typedef-style DWARF for these alias template specializations - perhaps lldb could not cache pretty printers for typedefs? (I guess the pretty printers shouldn't

[clang] [DebugInfo] Correct the line attribution for IF branches (PR #108300)

2024-09-19 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. Fair enough https://github.com/llvm/llvm-project/pull/108300 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [DebugInfo] Correct the line attribution for IF branches (PR #108300)

2024-09-12 Thread David Blaikie via cfe-commits
@@ -0,0 +1,45 @@ +// RUN: %clang_cc1 -debug-info-kind=limited -gno-column-info -triple=x86_64-pc-linux -emit-llvm %s -o - | FileCheck %s + +// The important thing is that the compare and the conditional branch have +// locs with the same scope (the lexical block for the 'if'). B

[clang] [DebugInfo] Correct the line attribution for IF branches (PR #108300)

2024-09-12 Thread David Blaikie via cfe-commits
@@ -0,0 +1,45 @@ +// RUN: %clang_cc1 -debug-info-kind=limited -gno-column-info -triple=x86_64-pc-linux -emit-llvm %s -o - | FileCheck %s + +// The important thing is that the compare and the conditional branch have +// locs with the same scope (the lexical block for the 'if'). B

[clang] [DebugInfo] Correct the line attribution for IF branches (PR #108300)

2024-09-12 Thread David Blaikie via cfe-commits
@@ -0,0 +1,45 @@ +// RUN: %clang_cc1 -debug-info-kind=limited -gno-column-info -triple=x86_64-pc-linux -emit-llvm %s -o - | FileCheck %s + +// The important thing is that the compare and the conditional branch have +// locs with the same scope (the lexical block for the 'if'). B

[clang] [clang][Sema] Fix diagnostic for function overloading in extern "C" (PR #106033)

2024-08-30 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/106033 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Fix diagnostic for function overloading in extern "C" (PR #106033)

2024-08-30 Thread David Blaikie via cfe-commits
dwblaikie wrote: > This make sense to me, @dwblaikie wdyt? Seems OK to me https://github.com/llvm/llvm-project/pull/106033 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Assert non-null enum definition in CGDebugInfo::CreateTypeDefinition(const EnumType*) (PR #105556)

2024-08-26 Thread David Blaikie via cfe-commits
dwblaikie wrote: What static analysis tool flagged this? Any idea why this particular null dereference, when LLVM/Clang have loads of assumed-non-null pointers that are dereferenced in a great many places? https://github.com/llvm/llvm-project/pull/105556 ___

[clang] [DebugInfo] Add flag to only emit referenced member functions (PR #87018)

2024-08-20 Thread David Blaikie via cfe-commits
dwblaikie wrote: > Looking forward to trying this out! > > Should the new flag have some docs and maybe be mentioned in the release > notes, or do we think it's not ready for prime time yet for some reason? I'm /pretty/ neutral on that - it's got pretty clear behavior, etc (& in fact some cla

[clang] [lld] [llvm] [mlir] [NFC][IWYU] Update Support library with IWYU. (PR #102707)

2024-08-12 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > The motivation is as usual IWYU and similar refactoring - to reduce build > > time and probablility of non-related source(s) recompile. > > I'm confused: as far as I know IWYU achieves the opposite of what you're > describing actually: it adds more includes than strictly n

[clang] [llvm] [Clang] Protect ObjCMethodList assignment operator against self-assignment (PR #97933)

2024-08-04 Thread David Blaikie via cfe-commits
dwblaikie wrote: Is there existing test coverage (like, if you add an assertion, instead of an if/return - do any tests hit the assertion)? or could you add some? https://github.com/llvm/llvm-project/pull/97933 ___ cfe-commits mailing list cfe-commits

[clang] [clang][CGDebugInfo] Don't generate an implicit 'this' parameter if one was specified explicitly (PR #100767)

2024-07-26 Thread David Blaikie via cfe-commits
https://github.com/dwblaikie approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/100767 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 8dd5742 - Fix aarch64-ptrauth.c to avoid writing to cwd which might not be writeable

2024-07-25 Thread David Blaikie via cfe-commits
Author: David Blaikie Date: 2024-07-25T21:52:14Z New Revision: 8dd574236ccaa0a183278396cfec3068b832651a URL: https://github.com/llvm/llvm-project/commit/8dd574236ccaa0a183278396cfec3068b832651a DIFF: https://github.com/llvm/llvm-project/commit/8dd574236ccaa0a183278396cfec3068b832651a.diff LOG:

[clang] [Clang] Fix null pointer dereference in enum debug info generation (PR #97105)

2024-07-24 Thread David Blaikie via cfe-commits
@@ -98,3 +98,6 @@ enum E8 { A8 = -128, B8 = 127 } x8; // CHECK-NOT: DIFlagEnumClass // CHECK: !DIEnumerator(name: "A8", value: -128) +// Forward declaration of an enum class. +enum class Color : int; +// CHECK-NOT: !DICompositeType(tag: DW_TAG_enumeration_type, name: "Color" -

[clang] [llvm] Revert "[PS4/PS5][Driver][DWARF] Always emit .debug_aranges for SCE t… (PR #99711)

2024-07-22 Thread David Blaikie via cfe-commits
dwblaikie wrote: also, if you're sending a pull request just because it's convenient (via the web UI "revert" button) or to run presubmits but not for review, please include the skip-presubmit-approval label so it's clear something isn't getting committed without needed review https://github.

[clang] [llvm] Revert "Add source file name for template instantiations in -ftime-trace" (PR #99534)

2024-07-21 Thread David Blaikie via cfe-commits
dwblaikie wrote: (if you don't need a code review for a change, you can commit it directly without a pull request - if you're making a PR not for code review but for presubmit checks, please label to `skip-precommit-approval` to clarify that you aren't waiting for approval (and that the change

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-07-16 Thread David Blaikie via cfe-commits
dwblaikie wrote: > > That's a pretty substantial policy change to propose, and this probably > > isn't the place to propose/discuss it. If that's your intent, probably best > > to take that up on discord. > > I am not proposing a policy change. I believe the current policy is aimed at > givin

  1   2   3   4   5   6   7   8   9   10   >