Re: [clang-tools-extra] r338017 - [clangd] Proof-of-concept query iterators for Dex symbol index

[Jeremy Morse via cfe-commits]

 [Resending with cfe-commits@, whoops]

Hi Kirill,

We believe this patch might be breaking one of the buildbots:

http://lab.llvm.org:8011/builders/clang-x86_64-linux-
abi-test/builds/29719

Which is complaining about the std::unique_ptr copy constructor being
called in DexIndexTests.cpp. It seems likely that returning a unique_ptr:

> std::unique_ptr
> createAnd(std::vector> Children) {
>   return llvm::make_unique(move(Children));
> }

And sites such as:

>  auto AndEmpty = createAnd({create(L0)});

Are triggering a bug in clang 3.7 and 3.8 where the move constructor isn't
correctly inferred:

https://godbolt.org/g/Aquug4

Wrapping everything in std::move will likely fix that, those two versions
of clang are still officially supported by LLVM/Clang.

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r333989 - Detect an incompatible VLA pointer assignment

[Jeremy Morse via cfe-commits]

Author: jmorse
Date: Tue Jun  5 02:18:26 2018
New Revision: 333989

URL: http://llvm.org/viewvc/llvm-project?rev=333989&view=rev
Log:
Detect an incompatible VLA pointer assignment

For pointer assignments of VLA types, Clang currently detects when array
dimensions _lower_ than a variable dimension differ, and reports a warning.
However it does not do the same when the _higher_ dimensions differ, a
case that GCC does catch.

These two pointer types

int (*foo)[1][bar][3];
int (*baz)[1][2][3];

are compatible with each another, and the program is well formed if
bar == 2, a matter that is the programmers problem. However the following:

int (*qux)[2][2][3];

would not be compatible with either, because the upper dimension differs
in size. Clang reports baz is incompatible with qux, but not that foo is
incompatible with qux because it doesn't check those higher dimensions.

Fix this by comparing array sizes on higher dimensions: if both are
constants but unequal then report incompatibility; if either dimension is
variable then we can't know either way.

Differential Revision: https://reviews.llvm.org/D47628

Modified:
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/test/Sema/vla.c

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=333989&r1=333988&r2=333989&view=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Tue Jun  5 02:18:26 2018
@@ -8601,6 +8601,38 @@ QualType ASTContext::mergeTypes(QualType
 QualType ResultType = mergeTypes(LHSElem, RHSElem, false, Unqualified);
 if (ResultType.isNull())
   return {};
+
+const VariableArrayType* LVAT = getAsVariableArrayType(LHS);
+const VariableArrayType* RVAT = getAsVariableArrayType(RHS);
+
+// If either side is a variable array, and both are complete, check whether
+// the current dimension is definite.
+if (LVAT || RVAT) {
+  auto SizeFetch = [this](const VariableArrayType* VAT,
+  const ConstantArrayType* CAT)
+  -> std::pair {
+if (VAT) {
+  llvm::APSInt TheInt;
+  Expr *E = VAT->getSizeExpr();
+  if (E && E->isIntegerConstantExpr(TheInt, *this))
+return std::make_pair(true, TheInt);
+  else
+return std::make_pair(false, TheInt);
+} else if (CAT) {
+return std::make_pair(true, CAT->getSize());
+} else {
+return std::make_pair(false, llvm::APInt());
+}
+  };
+
+  bool HaveLSize, HaveRSize;
+  llvm::APInt LSize, RSize;
+  std::tie(HaveLSize, LSize) = SizeFetch(LVAT, LCAT);
+  std::tie(HaveRSize, RSize) = SizeFetch(RVAT, RCAT);
+  if (HaveLSize && HaveRSize && !llvm::APInt::isSameValue(LSize, RSize))
+return {}; // Definite, but unequal, array dimension
+}
+
 if (LCAT && getCanonicalType(LHSElem) == getCanonicalType(ResultType))
   return LHS;
 if (RCAT && getCanonicalType(RHSElem) == getCanonicalType(ResultType))
@@ -8609,8 +8641,6 @@ QualType ASTContext::mergeTypes(QualType
   ArrayType::ArraySizeModifier(), 0);
 if (RCAT) return getConstantArrayType(ResultType, RCAT->getSize(),
   ArrayType::ArraySizeModifier(), 0);
-const VariableArrayType* LVAT = getAsVariableArrayType(LHS);
-const VariableArrayType* RVAT = getAsVariableArrayType(RHS);
 if (LVAT && getCanonicalType(LHSElem) == getCanonicalType(ResultType))
   return LHS;
 if (RVAT && getCanonicalType(RHSElem) == getCanonicalType(ResultType))

Modified: cfe/trunk/test/Sema/vla.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/vla.c?rev=333989&r1=333988&r2=333989&view=diff
==
--- cfe/trunk/test/Sema/vla.c (original)
+++ cfe/trunk/test/Sema/vla.c Tue Jun  5 02:18:26 2018
@@ -76,3 +76,16 @@ struct {
   ];
 };
 int (*use_implicitly_declared)() = implicitly_declared; // ok, was implicitly 
declared at file scope
+
+void VLAPtrAssign(int size) {
+  int array[1][2][3][size][4][5];
+  // This is well formed
+  int (*p)[2][3][size][4][5] = array;
+  // Last array dimension too large
+  int (*p2)[2][3][size][4][6] = array; // expected-warning {{incompatible 
pointer types}}
+  // Second array dimension too large
+  int (*p3)[20][3][size][4][5] = array; // expected-warning {{incompatible 
pointer types}}
+
+  // Not illegal in C, program _might_ be well formed if size == 3.
+  int (*p4)[2][size][3][4][5] = array;
+}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r351316 - Reapply [Tooling] Make clang-tool find libc++ dir on mac when running on a file without compilation database.

[Jeremy Morse via cfe-commits]

Hi Sam,

Unfortunately this trips up a variety of buildbots:

http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22376
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15053
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22376
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/3401
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8/builds/18177

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/22919

For the Windows machines at least, I don't believe lit can cope with
replicating shell subprocesses and thus the use of $(which...). (I could be
wrong there, but it matches up with the error messages).

"clang-check-mac-libcxx-fixed-compilation-db.cpp" sounds like it's
mac-specific, maybe only "REQUIRES: system-darwin" is needed?

--
Thanks,
Jeremy


>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r351316 - Reapply [Tooling] Make clang-tool find libc++ dir on mac when running on a file without compilation database.

[Jeremy Morse via cfe-commits]

We do rather need this working for our downstream merging to continue, and
to clear up the buildbots -- without objection I'll drop the  "REQUIRES:
system-darwin" line in there. Depending on what's actually supposed to be
tested that might be sufficient, but please do follow up.

--
Thanks,
Jeremy


>>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r351360 - Add a REQUIRES: darwin line for a mac test.

[Jeremy Morse via cfe-commits]

Author: jmorse
Date: Wed Jan 16 09:41:29 2019
New Revision: 351360

URL: http://llvm.org/viewvc/llvm-project?rev=351360&view=rev
Log:
Add a REQUIRES: darwin line for a mac test.

This test, apparently for macs, fails on Windows as lit can't emulate
the shell subprocess $(which...) correctly. Some other netbsd and linux
buildbots also fail here. Limit to macs as a temporary workaround.

Modified:
cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp

Modified: cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp?rev=351360&r1=351359&r2=351360&view=diff
==
--- cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp 
(original)
+++ cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp Wed 
Jan 16 09:41:29 2019
@@ -11,6 +11,6 @@
 // RUN: cp $(which clang-check) %t/mock-libcxx/bin/
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: %t/mock-libcxx/bin/clang-check -p "%t" "%t/test.cpp" -- -stdlib=libc++ 
-target x86_64-apple-darwin
-
+// REQUIRES: system-darwin
 #include 
 vector v;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r351316 - Reapply [Tooling] Make clang-tool find libc++ dir on mac when running on a file without compilation database.

[Jeremy Morse via cfe-commits]

Platform REQUIRES added in r351360, please do revert & fix if this test is
supposed to work elsewhere.

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r371663 - Start porting ivfsoverlay tests to Windows

[Jeremy Morse via cfe-commits]

Hi Reid,

On Wed, Sep 11, 2019 at 9:55 PM Reid Kleckner via cfe-commits
 wrote:
> +// XFAIL: windows

Looks like this should be system-windows, the PS4 buildbots [0] have a
windows host but target x86_64-scei-ps4, and croak on this change.

Assuming no-one else is looking at this, I'll commit a fix in ~30 mins.

[0] 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/28114

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r371726 - Switch "windows" to "system-windows" in some XFAILs

[Jeremy Morse via cfe-commits]

Author: jmorse
Date: Thu Sep 12 04:19:12 2019
New Revision: 371726

URL: http://llvm.org/viewvc/llvm-project?rev=371726&view=rev
Log:
Switch "windows" to "system-windows" in some XFAILs

The test failure mode appears to be due to the host machine rather than the
target. The PS4 buildbots are windows-hosted targeting x86_64-scei-ps4,
and are currently reporting these as unexpected failures:

  
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/28114

Modified:
cfe/trunk/test/Index/index-module-with-vfs.m
cfe/trunk/test/Modules/double-quotes.m
cfe/trunk/test/Modules/framework-public-includes-private.m
cfe/trunk/test/VFS/external-names.c
cfe/trunk/test/VFS/framework-import.m
cfe/trunk/test/VFS/implicit-include.c
cfe/trunk/test/VFS/include-mixed-real-and-virtual.c
cfe/trunk/test/VFS/include-real-from-virtual.c
cfe/trunk/test/VFS/include-virtual-from-real.c
cfe/trunk/test/VFS/include.c
cfe/trunk/test/VFS/incomplete-umbrella.m
cfe/trunk/test/VFS/module-import.m
cfe/trunk/test/VFS/real-path-found-first.m
cfe/trunk/test/VFS/relative-path.c
cfe/trunk/test/VFS/subframework-symlink.m
cfe/trunk/test/VFS/umbrella-framework-import-skipnonexist.m
cfe/trunk/test/VFS/vfsroot-include.c
cfe/trunk/test/VFS/vfsroot-module.m
cfe/trunk/test/VFS/vfsroot-with-overlay.c

Modified: cfe/trunk/test/Index/index-module-with-vfs.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/index-module-with-vfs.m?rev=371726&r1=371725&r2=371726&view=diff
==
--- cfe/trunk/test/Index/index-module-with-vfs.m (original)
+++ cfe/trunk/test/Index/index-module-with-vfs.m Thu Sep 12 04:19:12 2019
@@ -1,5 +1,5 @@
 // FIXME: PR43272
-// XFAIL: windows
+// XFAIL: system-windows
 
 @import ModuleNeedsVFS;
 

Modified: cfe/trunk/test/Modules/double-quotes.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/double-quotes.m?rev=371726&r1=371725&r2=371726&view=diff
==
--- cfe/trunk/test/Modules/double-quotes.m (original)
+++ cfe/trunk/test/Modules/double-quotes.m Thu Sep 12 04:19:12 2019
@@ -1,5 +1,5 @@
 // FIXME: PR43272
-// XFAIL: windows
+// XFAIL: system-windows
 
 // RUN: rm -rf %t
 // RUN: mkdir %t

Modified: cfe/trunk/test/Modules/framework-public-includes-private.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/framework-public-includes-private.m?rev=371726&r1=371725&r2=371726&view=diff
==
--- cfe/trunk/test/Modules/framework-public-includes-private.m (original)
+++ cfe/trunk/test/Modules/framework-public-includes-private.m Thu Sep 12 
04:19:12 2019
@@ -1,5 +1,5 @@
 // FIXME: PR43272
-// XFAIL: windows
+// XFAIL: system-windows
 
 // RUN: rm -rf %t
 // RUN: mkdir %t

Modified: cfe/trunk/test/VFS/external-names.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/VFS/external-names.c?rev=371726&r1=371725&r2=371726&view=diff
==
--- cfe/trunk/test/VFS/external-names.c (original)
+++ cfe/trunk/test/VFS/external-names.c Thu Sep 12 04:19:12 2019
@@ -2,7 +2,7 @@
 // RUN: sed -e "s@INPUT_DIR@%/S/Inputs@g" -e "s@OUT_DIR@%/t@g" -e 
"s@EXTERNAL_NAMES@false@" %S/Inputs/use-external-names.yaml > %t.yaml
 
 // FIXME: PR43272
-// XFAIL: windows
+// XFAIL: system-windows
 
 #include "external-names.h"
 #ifdef REINCLUDE

Modified: cfe/trunk/test/VFS/framework-import.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/VFS/framework-import.m?rev=371726&r1=371725&r2=371726&view=diff
==
--- cfe/trunk/test/VFS/framework-import.m (original)
+++ cfe/trunk/test/VFS/framework-import.m Thu Sep 12 04:19:12 2019
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -Werror -F %t -ivfsoverlay %t.yaml -fsyntax-only %s
 
 // FIXME: PR43272
-// XFAIL: windows
+// XFAIL: system-windows
 
 #import 
 

Modified: cfe/trunk/test/VFS/implicit-include.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/VFS/implicit-include.c?rev=371726&r1=371725&r2=371726&view=diff
==
--- cfe/trunk/test/VFS/implicit-include.c (original)
+++ cfe/trunk/test/VFS/implicit-include.c Thu Sep 12 04:19:12 2019
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -Werror -ivfsoverlay %t.yaml -I %t -include "not_real.h" 
-fsyntax-only %s
 
 // FIXME: PR43272
-// XFAIL: windows
+// XFAIL: system-windows
 
 void foo() {
   bar();

Modified: cfe/trunk/test/VFS/include-mixed-real-and-virtual.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/VFS/include-mixed-real-and-virtual.c?rev=371726&r1=371725&r2=371726&view=diff
==
--- cfe/trunk/test/VFS/include-

Re: r371663 - Start porting ivfsoverlay tests to Windows

[Jeremy Morse via cfe-commits]

On Thu, Sep 12, 2019 at 11:24 AM Jeremy Morse
 wrote:
> Assuming no-one else is looking at this, I'll commit a fix in ~30 mins.

r371726

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] 97c407d - [clangd] Make use of URIs in FileShardedIndex

[Jeremy Morse via cfe-commits]

Hi Kadir,

I'm seeing a couple of windows buildbots failing to build
FileIndexTests.cpp, even after the follow up in 0dedb43153e6:

  
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/32109
  http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/15808

(It looks like the follow-up fixes VS2017, but VS2019 is doing
something different?)

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [clang-tools-extra] [DebugInfo][RemoveDIs] Don't allocate one DPMarker per instruction (PR #79345)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse closed https://github.com/llvm/llvm-project/pull/79345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang-tools-extra] [clang] [DebugInfo][RemoveDIs] Don't allocate one DPMarker per instruction (PR #79345)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Landed in ddc4935

https://github.com/llvm/llvm-project/pull/79345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

I see what you're saying about the metadata being incorrect; I feel like I've 
seen it before, but can't pin it down. For the record, all the builds where we 
saw this assertion were thin/full LTO.

I've kicked off a reduction of a large reproducer that I have to hand; I'm not 
immensely confident that it'll complete in a reasonable timescale (i.e.: days) 
as it's a large project being reduced. If any of the other reporters have 
anything smaller they can reduce, that'd assist significantly.

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [dataflow] CXXOperatorCallExpr equal operator might not be a glvalue (PR #80991)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse updated 
https://github.com/llvm/llvm-project/pull/80991

>From 0d03870ef82fac51387c353bbe4e095e431d7ce8 Mon Sep 17 00:00:00 2001
From: Paul Semel 
Date: Wed, 7 Feb 2024 13:59:40 +
Subject: [PATCH] [dataflow] CXXOperatorCallExpr equal operator might not be a
 glvalue

Although in a normal implementation the assumption is reasonable, it
seems that some esoteric implementation are not returning a T&. This
should be handled correctly and the values be propagated.
---
 clang/lib/Analysis/FlowSensitive/Transfer.cpp | 14 +++-
 .../Analysis/FlowSensitive/TransferTest.cpp   | 36 +++
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/clang/lib/Analysis/FlowSensitive/Transfer.cpp 
b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
index bb3aec763c29ca..d73c9d25136279 100644
--- a/clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -535,7 +535,19 @@ class TransferVisitor : public 
ConstStmtVisitor {
 return;
 
   copyRecord(*LocSrc, *LocDst, Env);
-  Env.setStorageLocation(*S, *LocDst);
+
+  // If the expr is a glvalue, we can reasonably assume the operator is
+  // returning T& and thus we can assign it `LocDst`.
+  if (S->isGLValue()) {
+Env.setStorageLocation(*S, *LocDst);
+  } else if (S->getType()->isRecordType()) {
+// If the expr is a prvalue, we cannot really assume anything regarding
+// the new value being created. We should just propagate it to ensure a
+// `RecordValue` exist for it.
+if (Env.getValue(*S) == nullptr)
+  refreshRecordValue(*S, Env);
+  }
+
   return;
 }
 
diff --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index 8bbb04024dcce6..4a4224b42b0850 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -2313,6 +2313,42 @@ TEST(TransferTest, 
AssignmentOperatorWithInitAndInheritance) {
  ASTContext &ASTCtx) {});
 }
 
+TEST(TransferTest, AssignmentOperatorReturnsVoid) {
+  // This is a crash repro.
+  std::string Code = R"(
+struct S {
+  void operator=(S&& other);
+};
+void target() {
+  S s;
+  s = S();
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {});
+}
+
+TEST(TransferTest, AssignmentOperatorReturnsByValue) {
+  // This is a crash repro.
+  std::string Code = R"(
+struct S {
+  S operator=(S&& other);
+};
+void target() {
+  S s;
+  s = S();
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {});
+}
+
 TEST(TransferTest, CopyConstructor) {
   std::string Code = R"(
 struct A {

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

```

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Several decades later; I applied this check to the verifier and reduced around 
it:
```
diff --git a/llvm/lib/IR/Verifier.cpp b/llvm/lib/IR/Verifier.cpp
index b1cf81a3dbdc..9e2250b584b1 100644
--- a/llvm/lib/IR/Verifier.cpp
+++ b/llvm/lib/IR/Verifier.cpp
@@ -1421,6 +1421,9 @@ void Verifier::visitDISubprogram(const DISubprogram &N) {
   "invalid retained nodes, expected DILocalVariable, DILabel, "
   "DIImportedEntity or DIType",
   &N, Node, Op);
+  if (DIType *T = dyn_cast(Op)) {
+CheckDI(T->getScope() == &N, "wrong scope for thingy", T, 
T->getScope(), &N);
+  }
 }
   }
   CheckDI(!hasConflictingReferenceFlags(N.getFlags()),
```

Which produced these two IR files:
https://gist.github.com/jmorse/fc7d5479171b9943ae27d0f03cd9db5c
https://gist.github.com/jmorse/17040c19a096dd3780274f8e58d97b16
Which when linked with `llvm-link aa.ll bb.ll -o cc.ll -S` hit the verifier 
assertion, and have output IR which exhibits the problem you identified 
@dzhidzhoev , where the DICompositeType for `handle` ends up in one 
DISubprograms retainedNodes list but points its scope at a different 
DISubprogram. Seemingly this is something to do with the merging (or not 
merging) of distinct DISubprograms during the IR linker, unfortunately I've 
zero knowledge about that portion of LLVM.

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Rats; we should be able to pin down where the problem originates from -- would 
you be able to describe what's malformed about the metadata, as it's not clear 
to us (sorry). We'll probably be able to llvm-reduce (or similar) around that 
description.

Unfortunately IIRC it comes from a reasonably large codebase that we can't 
share, possibly @zmodem @dcci have more accessible sources? (Short response 
sorry; currently up a mountain).

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

...ah, actually is it malformed because there's a DICompositeType in the 
retainedNodes list for a DISubprogram? I remember that the verifier considered 
that illegal before your patch landed, but not after.

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [clang] [DebugInfo][RemoveDIs] Don't allocate one DPMarker per instruction (PR #79345)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse updated 
https://github.com/llvm/llvm-project/pull/79345

>From 0620bf77b4a8586dc1aa96d72bd088a3e601edd4 Mon Sep 17 00:00:00 2001
From: Jeremy Morse 
Date: Wed, 24 Jan 2024 16:33:16 +
Subject: [PATCH 1/4] [DebugInfo][RemoveDIs] Don't allocate one DPMarker per
 instruction

This is an optimisation patch that shouldn't have any functional effect.
There's no need for all instructions to have a DPMarker attached to them,
because not all instructions have adjacent DPValues (aka dbg.values).

This patch inserts the appropriate conditionals into functions like
BasicBlock::spliceDebugInfo to ensure we don't step on a null pointer when
there isn't a DPMarker allocated. Mostly, this is a case of calling
createMarker occasionally, which will create a marker on an instruction
if there isn't one there already.

Also folded into this is the use of adoptDbgValues, which is a natural
extension: if we have a sequence of instructions and debug records:

%foo = add i32 %0,...
# dbg_value { %foo, ...
# dbg_value { %bar, ...
%baz = add i32 %...
%qux = add i32 %...

and delete, for example, the %baz instruction, then the dbg_value records
would naturally be transferred onto the %qux instruction (they "fall down"
onto it). There's no point in creating and splicing DPMarkers in the case
shown when %qux doesn't have a DPMarker already, we can instead just change
the owner of %baz's DPMarker from %baz to %qux. This also avoids calling
setParent on every DPValue.

Update LoopRotationUtils: it was relying on each instruction having it's
own distinct end(), so that we could express ranges and lack-of-ranges.
That's no longer true though: so switch to storing the range of DPValues on
the next instruction when we want to consider it's range next time around
the loop (see the nearby comment).
---
 llvm/include/llvm/IR/Instruction.h|  5 ++
 llvm/lib/IR/BasicBlock.cpp| 59 +++
 llvm/lib/IR/DebugProgramInstruction.cpp   | 22 +--
 llvm/lib/IR/Instruction.cpp   | 47 ++-
 llvm/lib/Transforms/Utils/Local.cpp   |  2 +-
 .../Transforms/Utils/LoopRotationUtils.cpp| 20 ---
 llvm/unittests/IR/BasicBlockDbgInfoTest.cpp   | 11 ++--
 7 files changed, 108 insertions(+), 58 deletions(-)

diff --git a/llvm/include/llvm/IR/Instruction.h 
b/llvm/include/llvm/IR/Instruction.h
index fcd2ba838e7fd..d120ef603bafb 100644
--- a/llvm/include/llvm/IR/Instruction.h
+++ b/llvm/include/llvm/IR/Instruction.h
@@ -86,6 +86,11 @@ class Instruction : public User,
   /// Returns true if any DPValues are attached to this instruction.
   bool hasDbgValues() const;
 
+  /// Transfer any DPValues on the position \p It onto this instruction.
+  /// \returns true if adoption worked, false otherwise.
+  bool adoptDbgValues(BasicBlock *BB, InstListType::iterator It,
+  bool InsertAtHead);
+
   /// Erase any DPValues attached to this instruction.
   void dropDbgValues();
 
diff --git a/llvm/lib/IR/BasicBlock.cpp b/llvm/lib/IR/BasicBlock.cpp
index dca5283283847..c7b1bd9c3ede2 100644
--- a/llvm/lib/IR/BasicBlock.cpp
+++ b/llvm/lib/IR/BasicBlock.cpp
@@ -81,8 +81,10 @@ void BasicBlock::convertToNewDbgValues() {
   continue;
 }
 
-// Create a marker to store DPValues in. Technically we don't need to store
-// one marker per instruction, but that's a future optimisation.
+if (DPVals.empty())
+  continue;
+
+// Create a marker to store DPValues in.
 createMarker(&I);
 DPMarker *Marker = I.DbgMarker;
 
@@ -769,6 +771,7 @@ void BasicBlock::flushTerminatorDbgValues() {
 return;
 
   // Transfer DPValues from the trailing position onto the terminator.
+  createMarker(Term);
   Term->DbgMarker->absorbDebugValues(*TrailingDPValues, false);
   TrailingDPValues->eraseFromParent();
   deleteTrailingDPValues();
@@ -812,9 +815,10 @@ void 
BasicBlock::spliceDebugInfoEmptyBlock(BasicBlock::iterator Dest,
 if (!SrcTrailingDPValues)
   return;
 
-DPMarker *M = Dest->DbgMarker;
-M->absorbDebugValues(*SrcTrailingDPValues, InsertAtHead);
-SrcTrailingDPValues->eraseFromParent();
+if (!Dest->adoptDbgValues(Src, Src->end(), InsertAtHead))
+  // If we couldn't just assign the marker into Dest, delete the trailing
+  // DPMarker.
+  SrcTrailingDPValues->eraseFromParent();
 Src->deleteTrailingDPValues();
 return;
   }
@@ -882,7 +886,6 @@ void BasicBlock::spliceDebugInfo(BasicBlock::iterator Dest, 
BasicBlock *Src,
 }
 
 if (First->hasDbgValues()) {
-  DPMarker *CurMarker = Src->getMarker(First);
   // Place them at the front, it would look like this:
   //Dest
   //  |
@@ -890,8 +893,8 @@ void BasicBlock::spliceDebugInfo(BasicBlock::iterator Dest, 
BasicBlock *Src,
   // Src-block: B---B---B---B:::C
   //|   |
   //   First   Last

[llvm] [clang] [clang-tools-extra] [DebugInfo][RemoveDIs] Don't allocate one DPMarker per instruction (PR #79345)

[Jeremy Morse via cfe-commits]

jmorse wrote:

(Note that I've merged main into this branch for various reasons,)

I've adjusted `adoptDbgValues` to always clean up the `DPMarker` that it 
adopts, so that there's no return value for people to accidentally miss. This 
means that we have to test in `adoptDbgValues` whether we're adopting something 
from a trailing-DPMarker position, and clean that up too, rather than relying 
on the caller to do that.

(I suppose this is a classic case of premature optimisation)

https://github.com/llvm/llvm-project/pull/79345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [llvm] [DebugInfo][RemoveDIs] Add a DPValue implementation for instcombine sinking (PR #77930)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse closed https://github.com/llvm/llvm-project/pull/77930
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Hi,

We're seeing a crash with this reproducer 
https://gist.github.com/jmorse/b0248c3c9f9195487ffd7c7431a8d15e

llc: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2338: virtual void 
llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction *): Assertion 
`LScopes.getAbstractScopesList().size() == NumAbstractSubprograms && 
"getOrCreateAbstractScope() inserted an abstract subprogram scope"' failed.

I'd previously posted the reproducer on 
https://reviews.llvm.org/D144006#4656728 , however I'd anonymised the IR too 
much to the point where it was broken in unrelated ways. Revision 2 of the 
gist, as linked, should produce the crash. I suspect the extra lexical scopes 
reachable through the retained-nodes list also need to be explored when the 
LexicalScopes object gets constructed, to avoid scopes being added late and 
causing containers to invalidate iterators. (Which is what that assertion is 
there to detect).

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Hmmm, that's unexpected -- I reverted the revert (tree here, contains one 
unrelated commit: 
https://github.com/jmorse/llvm-project/tree/reapply-localvars-patch) and 
rebuilt. The assertion-failure occurs just with `llc foobar.ll -o out.o 
-filetype=obj`, where foobar.ll is the contents of the gist file linked. For 
the avoidance of doubt, it's:

$ wget 
https://gist.githubusercontent.com/jmorse/b0248c3c9f9195487ffd7c7431a8d15e/raw/e57ca0417b77fe04f9551a0a69ce58f0db697527/gistfile1.txt
$ mv gistfile1.txt foobar.ll
$ md5sum foobar.ll
d6c888d4e163545da596071fb5143377  foobar.ll

I don't think there's anything special about the build -- it's a 
CMAKE_BUILD_TYPE=Release build with LLVM_ENABLE_ASSERTIONS=On, built with 
clang-14 as shipped by ubuntu.

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang-tools-extra] [DebugInfo][RemoveDIs] Handle non-instr debug-info in GlobalISel (PR #75228)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Thanks -- I'm going to land this manually seeing how I don't trust githubs 
handling of squashing merge commits

https://github.com/llvm/llvm-project/pull/75228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang-tools-extra] [DebugInfo][RemoveDIs] Handle non-instr debug-info in GlobalISel (PR #75228)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse closed https://github.com/llvm/llvm-project/pull/75228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang-tools-extra] [DebugInfo][RemoveDIs] Handle non-instr debug-info in GlobalISel (PR #75228)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Committed in 087172258a50d5 

https://github.com/llvm/llvm-project/pull/75228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 121a49d - [LiveDebugValues] Add switches for using instr-ref variable locations

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2020-08-25T14:58:48+01:00
New Revision: 121a49d839d79f5a72be3e22a9d156c9e4b219dc

URL: 
https://github.com/llvm/llvm-project/commit/121a49d839d79f5a72be3e22a9d156c9e4b219dc
DIFF: 
https://github.com/llvm/llvm-project/commit/121a49d839d79f5a72be3e22a9d156c9e4b219dc.diff

LOG: [LiveDebugValues] Add switches for using instr-ref variable locations

This patch adds the -Xclang option
"-fexperimental-debug-variable-locations" and same LLVM CodeGen option,
to pick which variable location tracking solution to use.

Right now all the switch does is pick which LiveDebugValues
implementation to use, the normal VarLoc one or the instruction
referencing one in rGae6f78824031. Over time, the aim is to add fragments
of support in aid of the value-tracking RFC:

  http://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html

also controlled by this command line switch. That will slowly move
variable locations to be defined by an instruction calculating a value,
and a DBG_INSTR_REF instruction referring to that value. Thus, this is
going to grow into a "use the new kind of variable locations" switch,
rather than just "use the new LiveDebugValues implementation".

Differential Revision: https://reviews.llvm.org/D83048

Added: 
clang/test/Driver/debug-var-experimental-switch.c

Modified: 
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/Frontend/CompilerInvocation.cpp
llvm/include/llvm/CodeGen/CommandFlags.h
llvm/include/llvm/Target/TargetOptions.h
llvm/lib/CodeGen/CommandFlags.cpp
llvm/lib/CodeGen/LiveDebugValues/LiveDebugValues.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index cbd9df998e78..0f03373c4e25 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -325,6 +325,9 @@ ENUM_CODEGENOPT(DebuggerTuning, llvm::DebuggerKind, 2,
 /// emitted.
 VALUE_CODEGENOPT(DwarfVersion, 3, 0)
 
+/// Whether to use experimental new variable location tracking.
+CODEGENOPT(ValueTrackingVariableLocations, 1, 0)
+
 /// Whether we should emit CodeView debug information. It's possible to emit
 /// CodeView and DWARF into the same object.
 CODEGENOPT(EmitCodeView, 1, 0)

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 05aa79d06464..5da072ee4cc2 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3870,6 +3870,9 @@ def fdebug_pass_manager : Flag<["-"], 
"fdebug-pass-manager">,
 HelpText<"Prints debug information for the new pass manager">;
 def fno_debug_pass_manager : Flag<["-"], "fno-debug-pass-manager">,
 HelpText<"Disables debug printing for the new pass manager">;
+def fexperimental_debug_variable_locations : Flag<["-"],
+"fexperimental-debug-variable-locations">,
+HelpText<"Use experimental new value-tracking variable locations">;
 // The driver option takes the key as a parameter to the -msign-return-address=
 // and -mbranch-protection= options, but CC1 has a separate option so we
 // don't have to parse the parameter twice.

diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 566affa91b76..093650ac0066 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -520,6 +520,8 @@ static void initTargetOptions(DiagnosticsEngine &Diags,
   Options.EmitAddrsig = CodeGenOpts.Addrsig;
   Options.ForceDwarfFrameSection = CodeGenOpts.ForceDwarfFrameSection;
   Options.EmitCallSiteInfo = CodeGenOpts.EmitCallSiteInfo;
+  Options.ValueTrackingVariableLocations =
+  CodeGenOpts.ValueTrackingVariableLocations;
   Options.XRayOmitFunctionIndex = CodeGenOpts.XRayOmitFunctionIndex;
 
   Options.MCOptions.SplitDwarfFile = CodeGenOpts.SplitDwarfFile;

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 175985bd950a..0313ff4c363b 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -835,6 +835,9 @@ static bool ParseCodeGenArgs(CodeGenOptions &Opts, ArgList 
&Args, InputKind IK,
   llvm::is_contained(DebugEntryValueArchs, T.getArch()))
 Opts.EmitCallSiteInfo = true;
 
+  Opts.ValueTrackingVariableLocations =
+  Args.hasArg(OPT_fexperimental_debug_variable_locations);
+
   Opts.DisableO0ImplyOptNone = Args.hasArg(OPT_disable_O0_optnone);
   Opts.DisableRedZone = Args.hasArg(OPT_disable_red_zone);
   Opts.IndirectTlsSegRefs = Args.hasArg(OPT_mno_tls_direct_seg_refs);

diff  --git a/clang/test/Driver/debug-var-experimental-switch.c 
b/clang/test/Driver/debug-var-experimental-switch.c
new file mode 100644
index ..9c7a782e9e2b
--- /dev/null
+++ b/clang/test/Driver/debug-var-experimental

Re: [clang] d4934eb - [Syntax] Add iterators over children of syntax trees.

[Jeremy Morse via cfe-commits]

Hi Sam,

It looks like some Windows buildbots fail to build this, for example:

  http://lab.llvm.org:8011/#/builders/119/builds/349

In the build step,

  [Big long cl.exe command line for]
C:\buildbot\as-builder-2\x-aarch64\llvm-project\clang\lib\Tooling\Syntax\ComputeReplacements.cpp
  
C:\buildbot\as-builder-2\x-aarch64\llvm-project\clang\include\clang/Tooling/Syntax/Tree.h(225):
error C2512: 'clang::syntax::Tree::ConstChildIterator': no appropriate
default constructor available
  
C:\buildbot\as-builder-2\x-aarch64\llvm-project\clang\include\clang/Tooling/Syntax/Tree.h(225):
note: No constructor could take the source type, or constructor
overload resolution was ambiguous

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 651122f - [DebugInfo][InstrRef] Pre-land on-by-default-for-x86 changes

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2021-11-30T12:40:59Z
New Revision: 651122fc4ac92b93f36aab3b194de21065a0c48e

URL: 
https://github.com/llvm/llvm-project/commit/651122fc4ac92b93f36aab3b194de21065a0c48e
DIFF: 
https://github.com/llvm/llvm-project/commit/651122fc4ac92b93f36aab3b194de21065a0c48e.diff

LOG: [DebugInfo][InstrRef] Pre-land on-by-default-for-x86 changes

Over in D114631 and [0] there's a plan for turning instruction referencing
on by default for x86. This patch adds / removes all the relevant bits of
code, with the aim that the final patch is extremely small, for an easy
revert. It should just be a condition in CommandFlags.cpp and removing the
XFail on instr-ref-flag.ll.

[0] https://lists.llvm.org/pipermail/llvm-dev/2021-November/153653.html

Added: 
llvm/test/DebugInfo/X86/instr-ref-flag.ll

Modified: 
clang/include/clang/Driver/Options.td
llvm/include/llvm/CodeGen/CommandFlags.h
llvm/lib/CodeGen/CommandFlags.cpp

Removed: 
clang/test/Driver/debug-var-experimental-switch.c



diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index cf314bc73bf31..724eedd05da44 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5180,10 +5180,6 @@ defm debug_pass_manager : BoolOption<"f", 
"debug-pass-manager",
   CodeGenOpts<"DebugPassManager">, DefaultFalse,
   PosFlag,
   NegFlag>;
-def fexperimental_debug_variable_locations : Flag<["-"],
-"fexperimental-debug-variable-locations">,
-HelpText<"Use experimental new value-tracking variable locations">,
-MarshallingInfoFlag>;
 def fverify_debuginfo_preserve
 : Flag<["-"], "fverify-debuginfo-preserve">,
   HelpText<"Enable Debug Info Metadata preservation testing in "

diff  --git a/clang/test/Driver/debug-var-experimental-switch.c 
b/clang/test/Driver/debug-var-experimental-switch.c
deleted file mode 100644
index 9c7a782e9e2bb..0
--- a/clang/test/Driver/debug-var-experimental-switch.c
+++ /dev/null
@@ -1,2 +0,0 @@
-// RUN: %clang -Xclang -fexperimental-debug-variable-locations -fsyntax-only 
-disable-llvm-passes %s
-int main() {}

diff  --git a/llvm/include/llvm/CodeGen/CommandFlags.h 
b/llvm/include/llvm/CodeGen/CommandFlags.h
index ed3cd54df2727..73d39fecc268d 100644
--- a/llvm/include/llvm/CodeGen/CommandFlags.h
+++ b/llvm/include/llvm/CodeGen/CommandFlags.h
@@ -130,6 +130,7 @@ bool getEnableMachineFunctionSplitter();
 bool getEnableDebugEntryValues();
 
 bool getValueTrackingVariableLocations();
+Optional getExplicitValueTrackingVariableLocations();
 
 bool getForceDwarfFrameSection();
 
@@ -170,6 +171,10 @@ void setFunctionAttributes(StringRef CPU, StringRef 
Features, Function &F);
 /// Set function attributes of functions in Module M based on CPU,
 /// Features, and command line flags.
 void setFunctionAttributes(StringRef CPU, StringRef Features, Module &M);
+
+/// Should value-tracking variable locations / instruction referencing be
+/// enabled by default for this triple?
+bool getDefaultValueTrackingVariableLocations(const llvm::Triple &T);
 } // namespace codegen
 } // namespace llvm
 

diff  --git a/llvm/lib/CodeGen/CommandFlags.cpp 
b/llvm/lib/CodeGen/CommandFlags.cpp
index a1ff02178ffae..ecf3d931fc33b 100644
--- a/llvm/lib/CodeGen/CommandFlags.cpp
+++ b/llvm/lib/CodeGen/CommandFlags.cpp
@@ -90,7 +90,7 @@ CGOPT(bool, EnableAddrsig)
 CGOPT(bool, EmitCallSiteInfo)
 CGOPT(bool, EnableMachineFunctionSplitter)
 CGOPT(bool, EnableDebugEntryValues)
-CGOPT(bool, ValueTrackingVariableLocations)
+CGOPT_EXP(bool, ValueTrackingVariableLocations)
 CGOPT(bool, ForceDwarfFrameSection)
 CGOPT(bool, XRayOmitFunctionIndex)
 CGOPT(bool, DebugStrictDwarf)
@@ -534,12 +534,17 @@ codegen::InitTargetOptionsFromCodeGenFlags(const Triple 
&TheTriple) {
   Options.EmitAddrsig = getEnableAddrsig();
   Options.EmitCallSiteInfo = getEmitCallSiteInfo();
   Options.EnableDebugEntryValues = getEnableDebugEntryValues();
-  Options.ValueTrackingVariableLocations = getValueTrackingVariableLocations();
   Options.ForceDwarfFrameSection = getForceDwarfFrameSection();
   Options.XRayOmitFunctionIndex = getXRayOmitFunctionIndex();
   Options.DebugStrictDwarf = getDebugStrictDwarf();
   Options.LoopAlignment = getAlignLoops();
 
+  if (auto Opt = getExplicitValueTrackingVariableLocations())
+Options.ValueTrackingVariableLocations = *Opt;
+  else
+Options.ValueTrackingVariableLocations =
+getDefaultValueTrackingVariableLocations(TheTriple);
+
   Options.MCOptions = mc::InitMCTargetOptionsFromFlags();
 
   Options.ThreadModel = getThreadModel();
@@ -692,3 +697,7 @@ void codegen::setFunctionAttributes(StringRef CPU, 
StringRef Features,
   for (Function &F : M)
 setFunctionAttributes(CPU, Features, F);
 }
+
+bool codegen::getDefaultValueTrackingVariableLocations(const llvm::Triple &T) {
+  return false;
+}

diff  --git a/llvm/test/DebugInfo/X86/instr-ref-flag.l

[clang] 16c6e0f - Quote a python executable path

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2020-03-04T15:23:48Z
New Revision: 16c6e0f387e957d21ab90c8694c11cd269ec7719

URL: 
https://github.com/llvm/llvm-project/commit/16c6e0f387e957d21ab90c8694c11cd269ec7719
DIFF: 
https://github.com/llvm/llvm-project/commit/16c6e0f387e957d21ab90c8694c11cd269ec7719.diff

LOG: Quote a python executable path

On my Windows machine at least, the path to python contains a space.

Added: 


Modified: 
clang/test/lit.cfg.py

Removed: 




diff  --git a/clang/test/lit.cfg.py b/clang/test/lit.cfg.py
index 08d15edac94c..bdf3b1179225 100644
--- a/clang/test/lit.cfg.py
+++ b/clang/test/lit.cfg.py
@@ -81,7 +81,7 @@
 config.test_source_root, "Analysis", "check-analyzer-fixit.py")
 config.substitutions.append(
 ('%check_analyzer_fixit',
- '%s %s' % (config.python_executable, check_analyzer_fixit_path)))
+ '"%s" %s' % (config.python_executable, check_analyzer_fixit_path)))
 
 llvm_config.add_tool_substitutions(tools, tool_dirs)
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] d4f9675 - [analyzer] decode() a bytes object to make Python3 happy

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2020-03-04T17:12:48Z
New Revision: d4f9675b5509e26573058318682a9ed5d7aaf320

URL: 
https://github.com/llvm/llvm-project/commit/d4f9675b5509e26573058318682a9ed5d7aaf320
DIFF: 
https://github.com/llvm/llvm-project/commit/d4f9675b5509e26573058318682a9ed5d7aaf320.diff

LOG: [analyzer] decode() a bytes object to make Python3 happy

The output of subprocess.check_output is decode()'d through the rest of
this python program, but one appears to have been missed for the output
of the call to "clang -print-file-name=include".

On Windows, with Python 3.6, this leads to the 'args' array being a mix of
bytes and strings, which causes exceptions later down the line.

I can't easily test with python2 on Windows, but python2 on Ubuntu 18.04
was happy with this change.

Added: 


Modified: 
clang/test/Analysis/check-analyzer-fixit.py

Removed: 




diff  --git a/clang/test/Analysis/check-analyzer-fixit.py 
b/clang/test/Analysis/check-analyzer-fixit.py
index 1d159aedec91..6a8f6859f816 100644
--- a/clang/test/Analysis/check-analyzer-fixit.py
+++ b/clang/test/Analysis/check-analyzer-fixit.py
@@ -63,7 +63,7 @@ def run_test_once(args, extra_args):
 
 try:
 builtin_include_dir = subprocess.check_output(
-['clang', '-print-file-name=include'], stderr=subprocess.STDOUT)
+['clang', '-print-file-name=include'], 
stderr=subprocess.STDOUT).decode()
 except subprocess.CalledProcessError as e:
 print('Cannot print Clang include directory: ' + e.output.decode())
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 6c0a160 - Rename a flang test case

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2019-10-30T13:29:47Z
New Revision: 6c0a160c2d33e54aecf1538bf7c85d8da92051be

URL: 
https://github.com/llvm/llvm-project/commit/6c0a160c2d33e54aecf1538bf7c85d8da92051be
DIFF: 
https://github.com/llvm/llvm-project/commit/6c0a160c2d33e54aecf1538bf7c85d8da92051be.diff

LOG: Rename a flang test case

On Windows and macOS, the filesystem is case insensitive, and these files
interfere with each other. Reading through, the case of the file extension
is part of the test. I've altered the rest of the name instead.

Added: 
clang/test/Driver/flang/flang_ucase.F90

Modified: 
clang/test/Driver/flang/flang.f90

Removed: 
clang/test/Driver/flang/flang.F90



diff  --git a/clang/test/Driver/flang/flang.f90 
b/clang/test/Driver/flang/flang.f90
index 56c1ace6f860..9d47c7c90225 100644
--- a/clang/test/Driver/flang/flang.f90
+++ b/clang/test/Driver/flang/flang.f90
@@ -1,6 +1,6 @@
 ! Check that flang -fc1 is invoked when in --driver-mode=flang.
 
-! This is a copy of flang.F90 because the driver has logic in it which
+! This is a copy of flang_ucase.F90 because the driver has logic in it which
 ! 
diff erentiates between F90 and f90 files. Flang will not treat these files
 ! 
diff erently.
 

diff  --git a/clang/test/Driver/flang/flang.F90 
b/clang/test/Driver/flang/flang_ucase.F90
similarity index 98%
rename from clang/test/Driver/flang/flang.F90
rename to clang/test/Driver/flang/flang_ucase.F90
index 37553c7c2760..323afb21dccf 100644
--- a/clang/test/Driver/flang/flang.F90
+++ b/clang/test/Driver/flang/flang_ucase.F90
@@ -48,4 +48,4 @@
 ! CHECK-EMIT-OBJ-DAG: "-o" "{{[^"]*}}.o"
 
 ! Should end in the input file.
-! ALL: "{{.*}}flang.F90"{{$}}
+! ALL: "{{.*}}flang_ucase.F90"{{$}}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Jeremy Morse via cfe-commits]

FYI, in llvmorg-10-init-8612-g6c0a160c2d3 [0] I've renamed one of the
two files, Windows too has a case-insensitive filesystem layer and
this broke our CI. (I think I've preserved the original intention of
the tests).

[0] 
https://github.com/llvm/llvm-project/commit/6c0a160c2d33e54aecf1538bf7c85d8da92051be

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 6b45e1b - Revert "[clang] Report sanitizer blacklist as a dependency in cc1"

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2019-11-08T12:07:42Z
New Revision: 6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8

URL: 
https://github.com/llvm/llvm-project/commit/6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8
DIFF: 
https://github.com/llvm/llvm-project/commit/6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8.diff

LOG: Revert "[clang] Report sanitizer blacklist as a dependency in cc1"

This reverts commit 03b84e4f6d0e1c04f22d69cc445f36e1f713beb4.

This breaks dfsan tests with a linking failure, in for example this build:

  http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24312

Reverting this patch locally makes those tests succeed.

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/include/clang/Driver/SanitizerArgs.h
clang/lib/Driver/SanitizerArgs.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Driver/fsanitize-blacklist.c
clang/test/Frontend/dependency-gen.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index c2e30a16b8da..dcd2976a97f2 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -979,9 +979,6 @@ def fno_sanitize_EQ : CommaJoined<["-"], "fno-sanitize=">, 
Group,
 def fsanitize_blacklist : Joined<["-"], "fsanitize-blacklist=">,
   Group,
   HelpText<"Path to blacklist file for sanitizers">;
-def fsanitize_system_blacklist : Joined<["-"], "fsanitize-system-blacklist=">,
-  HelpText<"Path to system blacklist file for sanitizers">,
-  Flags<[CC1Option]>;
 def fno_sanitize_blacklist : Flag<["-"], "fno-sanitize-blacklist">,
  Group,
  HelpText<"Don't use blacklist file for 
sanitizers">;

diff  --git a/clang/include/clang/Driver/SanitizerArgs.h 
b/clang/include/clang/Driver/SanitizerArgs.h
index 0aebf8cb225d..c37499e0f201 100644
--- a/clang/include/clang/Driver/SanitizerArgs.h
+++ b/clang/include/clang/Driver/SanitizerArgs.h
@@ -25,8 +25,8 @@ class SanitizerArgs {
   SanitizerSet RecoverableSanitizers;
   SanitizerSet TrapSanitizers;
 
-  std::vector UserBlacklistFiles;
-  std::vector SystemBlacklistFiles;
+  std::vector BlacklistFiles;
+  std::vector ExtraDeps;
   int CoverageFeatures = 0;
   int MsanTrackOrigins = 0;
   bool MsanUseAfterDtor = true;

diff  --git a/clang/lib/Driver/SanitizerArgs.cpp 
b/clang/lib/Driver/SanitizerArgs.cpp
index 8937197c253c..cc6c5e6ef438 100644
--- a/clang/lib/Driver/SanitizerArgs.cpp
+++ b/clang/lib/Driver/SanitizerArgs.cpp
@@ -557,35 +557,29 @@ SanitizerArgs::SanitizerArgs(const ToolChain &TC,
 
   // Setup blacklist files.
   // Add default blacklist from resource directory.
-  addDefaultBlacklists(D, Kinds, SystemBlacklistFiles);
+  addDefaultBlacklists(D, Kinds, BlacklistFiles);
   // Parse -f(no-)sanitize-blacklist options.
   for (const auto *Arg : Args) {
 if (Arg->getOption().matches(options::OPT_fsanitize_blacklist)) {
   Arg->claim();
   std::string BLPath = Arg->getValue();
   if (llvm::sys::fs::exists(BLPath)) {
-UserBlacklistFiles.push_back(BLPath);
+BlacklistFiles.push_back(BLPath);
+ExtraDeps.push_back(BLPath);
   } else {
 D.Diag(clang::diag::err_drv_no_such_file) << BLPath;
   }
 } else if (Arg->getOption().matches(options::OPT_fno_sanitize_blacklist)) {
   Arg->claim();
-  UserBlacklistFiles.clear();
-  SystemBlacklistFiles.clear();
+  BlacklistFiles.clear();
+  ExtraDeps.clear();
 }
   }
   // Validate blacklists format.
   {
 std::string BLError;
 std::unique_ptr SCL(
-llvm::SpecialCaseList::create(UserBlacklistFiles, BLError));
-if (!SCL.get())
-  D.Diag(clang::diag::err_drv_malformed_sanitizer_blacklist) << BLError;
-  }
-  {
-std::string BLError;
-std::unique_ptr SCL(
-llvm::SpecialCaseList::create(SystemBlacklistFiles, BLError));
+llvm::SpecialCaseList::create(BlacklistFiles, BLError));
 if (!SCL.get())
   D.Diag(clang::diag::err_drv_malformed_sanitizer_blacklist) << BLError;
   }
@@ -958,15 +952,15 @@ void SanitizerArgs::addArgs(const ToolChain &TC, const 
llvm::opt::ArgList &Args,
 CmdArgs.push_back(
 Args.MakeArgString("-fsanitize-trap=" + toString(TrapSanitizers)));
 
-  for (const auto &BLPath : UserBlacklistFiles) {
+  for (const auto &BLPath : BlacklistFiles) {
 SmallString<64> BlacklistOpt("-fsanitize-blacklist=");
 BlacklistOpt += BLPath;
 CmdArgs.push_back(Args.MakeArgString(BlacklistOpt));
   }
-  for (const auto &BLPath : SystemBlacklistFiles) {
-SmallString<64> BlacklistOpt("-fsanitize-system-blacklist=");
-BlacklistOpt += BLPath;
-CmdArgs.push_back(Args.MakeArgString(BlacklistOpt));
+  for (const auto &Dep : ExtraDeps) {
+SmallString<64> ExtraDepOpt("-fdepfile-entry=");
+ExtraDepOpt += Dep;
+CmdArgs.push_back(Ar

Re: [clang] 03b84e4 - [clang] Report sanitizer blacklist as a dependency in cc1

[Jeremy Morse via cfe-commits]

Hi Jan,

As the dfsan tests have been failing for a bit, I've reverted this in
6b45e1bc, and the follow-up patch in d6be9273c, to clear the
buildbots.

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] 03b84e4 - [clang] Report sanitizer blacklist as a dependency in cc1

[Jeremy Morse via cfe-commits]

Hi Jan,

The x86_64 sanitizer was failing:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24326

And then immediately after the reverts landed:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24327

check-dfsan passes. I don't have any explanation as to why this might
be the case sorry (and it seems fairly odd), but I managed to
reproduce it on a Ubuntu 19.04 VM.

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 737394c - Revert "clang: Treat ieee mode as the default for denormal-fp-math"

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2020-03-05T10:55:24Z
New Revision: 737394c490444e968a6f640b99a6614567ca7f28

URL: 
https://github.com/llvm/llvm-project/commit/737394c490444e968a6f640b99a6614567ca7f28
DIFF: 
https://github.com/llvm/llvm-project/commit/737394c490444e968a6f640b99a6614567ca7f28.diff

LOG: Revert "clang: Treat ieee mode as the default for denormal-fp-math"

This reverts commit c64ca93053af235bac0ca4dcdcd21c8882478310.

This patch tripped a few build bots:

  http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/24703/
  http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13465/
  http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/15994/

Reverting to clear the bots.

Added: 


Modified: 
clang/include/clang/Basic/CodeGenOptions.h
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGenCUDA/flush-denormals.cu
clang/test/CodeGenCUDA/propagate-metadata.cu
clang/test/CodeGenOpenCL/amdgpu-features.cl
clang/test/Driver/cuda-flush-denormals-to-zero.cu
clang/test/Driver/denormal-fp-math.c
clang/test/Driver/fp-model.c

Removed: 




diff  --git a/clang/include/clang/Basic/CodeGenOptions.h 
b/clang/include/clang/Basic/CodeGenOptions.h
index d435bebcdcf9..0a28edefa1e6 100644
--- a/clang/include/clang/Basic/CodeGenOptions.h
+++ b/clang/include/clang/Basic/CodeGenOptions.h
@@ -164,10 +164,10 @@ class CodeGenOptions : public CodeGenOptionsBase {
   std::string FloatABI;
 
   /// The floating-point denormal mode to use.
-  llvm::DenormalMode FPDenormalMode = llvm::DenormalMode::getIEEE();
+  llvm::DenormalMode FPDenormalMode;
 
-  /// The floating-point denormal mode to use, for float.
-  llvm::DenormalMode FP32DenormalMode = llvm::DenormalMode::getIEEE();
+  /// The floating-point subnormal mode to use, for float.
+  llvm::DenormalMode FP32DenormalMode;
 
   /// The float precision limit to use, if non-empty.
   std::string LimitFloatPrecision;

diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index 88ce205228fd..400ff9d86664 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -623,7 +623,8 @@ class ToolChain {
   const llvm::opt::ArgList &DriverArgs,
   Action::OffloadKind DeviceOffloadKind,
   const llvm::fltSemantics *FPType = nullptr) const {
-return llvm::DenormalMode::getIEEE();
+// FIXME: This should be IEEE when default handling is fixed.
+return llvm::DenormalMode::getInvalid();
   }
 };
 

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index c8da2d86490f..d387a1dc2079 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2548,13 +2548,8 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
   ReciprocalMath = false;
   SignedZeros = true;
   // -fno_fast_math restores default denormal and fpcontract handling
-  FPContract = "";
   DenormalFPMath = DefaultDenormalFPMath;
-
-  // FIXME: The target may have picked a non-IEEE default mode here based 
on
-  // -cl-denorms-are-zero. Should the target consider -fp-model 
interaction?
-  DenormalFP32Math = DefaultDenormalFP32Math;
-
+  FPContract = "";
   StringRef Val = A->getValue();
   if (OFastEnabled && !Val.equals("fast")) {
   // Only -ffp-model=fast is compatible with OFast, ignore.
@@ -2731,9 +2726,7 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
   FPExceptionBehavior = "strict";
   // -fno_unsafe_math_optimizations restores default denormal handling
   DenormalFPMath = DefaultDenormalFPMath;
-
-  // The target may have opted to flush just f32 by default, so force IEEE.
-  DenormalFP32Math = llvm::DenormalMode::getIEEE();
+  DenormalFP32Math = DefaultDenormalFP32Math;
   break;
 
 case options::OPT_Ofast:
@@ -2774,12 +2767,11 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
 if (StrictFPModel) {
   // If -ffp-model=strict has been specified on command line but
   // subsequent options conflict then emit warning diagnostic.
+  // TODO: How should this interact with DenormalFP32Math?
   if (HonorINFs && HonorNaNs &&
 !AssociativeMath && !ReciprocalMath &&
 SignedZeros && TrappingMath && RoundingFPMath &&
-(FPContract.equals("off") || FPContract.empty()) &&
-DenormalFPMath == llvm::DenormalMode::getIEEE() &&
-DenormalFP32Math == llvm::DenormalMode::getIEEE())
+(FPContract.equals("off") || FPContract.empty()))
 // OK: Current Arg doesn't conflict with -ffp-model=strict
 ;
   else {
@@ -2833,8 +2825,7 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
 Cm

Re: [clang] c64ca93 - clang: Treat ieee mode as the default for denormal-fp-math

[Jeremy Morse via cfe-commits]

Hi Matt,

FYI several build bots tripped on this commit:

  http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/24703/
  
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13465/
  http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/15994/

I've reverted the commit in 737394c490444e968a6f640b99a6614567ca7f28
to clear the bots.

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [DebugInfo] Make a test more robust (PR #106463)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/106463
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [DebugInfo][RemoveDIs] Use iterator-inserters in clang (PR #102006)

[Jeremy Morse via cfe-commits]

jmorse wrote:

(I can't replicate the buildkite windows failure locally, will commit and see 
what actually goes wrong)

https://github.com/llvm/llvm-project/pull/102006
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [DebugInfo][RemoveDIs] Use iterator-inserters in clang (PR #102006)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse closed 
https://github.com/llvm/llvm-project/pull/102006
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] d12250c - [NFC][Clang] clang-format a function declaration

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2024-08-12T09:49:55+01:00
New Revision: d12250ca7bea22ed12caf44fe80b203d83db75bb

URL: 
https://github.com/llvm/llvm-project/commit/d12250ca7bea22ed12caf44fe80b203d83db75bb
DIFF: 
https://github.com/llvm/llvm-project/commit/d12250ca7bea22ed12caf44fe80b203d83db75bb.diff

LOG: [NFC][Clang] clang-format a function declaration

Added: 


Modified: 
clang/lib/CodeGen/CGCleanup.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCleanup.cpp b/clang/lib/CodeGen/CGCleanup.cpp
index b1af4a0a97884b..5d253c92a38a81 100644
--- a/clang/lib/CodeGen/CGCleanup.cpp
+++ b/clang/lib/CodeGen/CGCleanup.cpp
@@ -299,9 +299,10 @@ static void createStoreInstBefore(llvm::Value *value, 
Address addr,
   store->setAlignment(addr.getAlignment().getAsAlign());
 }
 
-static llvm::LoadInst *createLoadInstBefore(Address addr, const Twine &name,
-llvm::BasicBlock::iterator 
beforeInst,
-CodeGenFunction &CGF) {
+static llvm::LoadInst *
+createLoadInstBefore(Address addr, const Twine &name,
+ llvm::BasicBlock::iterator beforeInst,
+ CodeGenFunction &CGF) {
   return new llvm::LoadInst(addr.getElementType(), addr.emitRawPointer(CGF),
 name, false, addr.getAlignment().getAsAlign(),
 beforeInst);



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [DebugInfo][RemoveDIs] Use iterator-inserters in clang (PR #102006)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Clang-formatted the declaration I touched in d12250ca7be, the other matters 
were already present in the code so I've shied away from addressing them.

https://github.com/llvm/llvm-project/pull/102006
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS4/PS5][Driver] Allow -static in PlayStation drivers (PR #102020)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

In lieu of Paul for a bit of time, LGTM.

I feel like the check for matching the linker-line could be made even stronger 
(one wonders how many options end with 'ld"', but it's probably good enough.

https://github.com/llvm/llvm-project/pull/102020
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #94100)

[Jeremy Morse via cfe-commits]

jmorse wrote:

G'day -- we've got some tests for -O0 that, with this patch applied, generate 
different code with-and-without the `-g` flag, if `-fdebug-info-for-profiling` 
is enabled. Example godbolt: https://godbolt.org/z/qooo5Eah1 .

It seems the intention of this patch is generating additional loads and stores 
with debug-info enabled, which is usually highly undesirable. It's guarded by 
`-fdebug-info-for-profiling`, however we (Sony) use this flag in a bunch of 
places, and would prefer it to continue generating stable + consistent code. A 
couple of possibilities:
 * Put this behaviour behind a cc1 flag, I think that was the plan in the 
original PR?
 * Instead of creating an alloca,  store+load, and dbg.declare, connect a 
dbg.value to the relevant pointer Value. 

The 2nd point is more work, but it means you're only adding more debug-info, 
and nothing else. A dbg.value connected to the pointer Value is the inevitable 
consequence of the alloca+store+load idiom after mem2reg/SROA anyway.

https://github.com/llvm/llvm-project/pull/94100
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #94100)

[Jeremy Morse via cfe-commits]

jmorse wrote:

dblaikie wrote:
>  I hope that isn't the intent, I thought the intent was just [...]

Ah, by which I mean "it's not an accident",

> By just specifying -g Even without -fdebug-info-for-profiling it is going to 
> introduce debug variables as a sequence of alloca-store-load too, so is it a 
> requirement to guarantee -O0 output stays identical with or without debug 
> info?

It's a strong objective of LLVM in general to ensure debug-info doesn't have an 
effect on codegen decisions -- it just makes everything unreliable and hard to 
predict. It can cause situations where an end user finds their programs behave 
differently with -g. Having a cc1 option to enable this kind of behaviour is 
fine as they're relatively experimental, for us the issue is that it's 
affecting an existing driver option.

> Emitting a dbg.value was what I originally though of, but there is a IR 
> validation pass after frontend codegen that does not permit it, not sure if 
> there's other design reason for this check

Interesting -- I'll admit I'm not especially familiar with stuff right at the 
front end, but I'm sure I've seen some emails go past about handling dbg.values 
earlier than normal. @SLTozer @OCHyams were there some Swift related patches 
that got SROA handling dbg.values correctly, and if so, maybe it's alright for 
clang to do it too? (@jmorse is still catching up with email).

https://github.com/llvm/llvm-project/pull/94100
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] (New) Add option to generate additional debug info for expression dereferencing pointer to pointers (PR #95298)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse commented:

Looks good in principle, with a couple of nits.

https://github.com/llvm/llvm-project/pull/95298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] (New) Add option to generate additional debug info for expression dereferencing pointer to pointers (PR #95298)

[Jeremy Morse via cfe-commits]

@@ -5746,6 +5746,57 @@ void 
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
   Var->addDebugInfo(GVE);
 }
 
+void CGDebugInfo::EmitPseudoVariable(CGBuilderTy &Builder,
+ llvm::Instruction *Value, QualType Ty) {
+  // Only when -g2 or above is specified, debug info for variables will be
+  // generated.
+  if (CGM.getCodeGenOpts().getDebugInfo() <=
+  llvm::codegenoptions::DebugLineTablesOnly)
+return;
+
+  llvm::DILocation *DIL = Value->getDebugLoc().get();
+  if (!DIL)
+return;
+
+  llvm::DIFile *Unit = DIL->getFile();
+  llvm::DIType *Type = getOrCreateType(Ty, Unit);
+
+  // Check if Value is already a declared variable and has debug info, in this
+  // case we have nothing to do. Clang emits declared variable as alloca, and

jmorse wrote:

```suggestion
  // case we have nothing to do. Clang emits declared variable as alloca, and
```
```suggestion
  // case we have nothing to do. Clang emits declared variables as alloca, and
```

https://github.com/llvm/llvm-project/pull/95298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] (New) Add option to generate additional debug info for expression dereferencing pointer to pointers (PR #95298)

[Jeremy Morse via cfe-commits]

@@ -5746,6 +5746,57 @@ void 
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
   Var->addDebugInfo(GVE);
 }
 
+void CGDebugInfo::EmitPseudoVariable(CGBuilderTy &Builder,
+ llvm::Instruction *Value, QualType Ty) {
+  // Only when -g2 or above is specified, debug info for variables will be
+  // generated.
+  if (CGM.getCodeGenOpts().getDebugInfo() <=
+  llvm::codegenoptions::DebugLineTablesOnly)
+return;
+
+  llvm::DILocation *DIL = Value->getDebugLoc().get();
+  if (!DIL)
+return;
+
+  llvm::DIFile *Unit = DIL->getFile();
+  llvm::DIType *Type = getOrCreateType(Ty, Unit);
+
+  // Check if Value is already a declared variable and has debug info, in this
+  // case we have nothing to do. Clang emits declared variable as alloca, and
+  // it is loaded upon use, so we identify such pattern here.
+  if (llvm::LoadInst *Load = dyn_cast(Value)) {
+llvm::Value *Var = Load->getPointerOperand();
+// There can be implicit type cast applied on a variable if it is an opaque
+// ptr, in this case its debug info may not match the actual type of object
+// being used as in the next instruction, so we will need to emit a pseudo
+// variable for type-casted value.
+auto DeclareTypeMatches = [&](auto *DbgDeclare) {
+  return DbgDeclare->getVariable()->getType() == Type;
+};
+if (any_of(llvm::findDbgDeclares(Var), DeclareTypeMatches) ||
+any_of(llvm::findDVRDeclares(Var), DeclareTypeMatches))
+  return;
+  }
+
+  // Find the correct location to insert the debug value.
+  llvm::BasicBlock *InsertBB = Value->getParent();
+  llvm::Instruction *InsertBefore = Value->getIterator()->getNextNode();
+  if (llvm::InvokeInst *Invoke = dyn_cast(Value)) {
+InsertBB = Invoke->getNormalDest();
+InsertBefore = InsertBB->size() > 0 ? &(InsertBB->front()) : nullptr;
+  }

jmorse wrote:

Part of the move towards debug-info away from intrinsics involves not inserting 
with raw instruction pointers, but instead iterators [0]. In practice I believe 
all that needs to be done is using `InsertBB->begin()` to fetch an iterator, 
you'll likely need to take `end()` and check it below for the empty-block case.

I understand #94224 provides a more graceful solution by allowing insertion at 
end(), however that won't land for a short while.

[0] 
https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939

https://github.com/llvm/llvm-project/pull/95298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] (New) Add option to generate additional debug info for expression dereferencing pointer to pointers (PR #95298)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse edited https://github.com/llvm/llvm-project/pull/95298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] (New) Add option to generate additional debug info for expression dereferencing pointer to pointers (PR #95298)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM, thanks for rapidly rewriting this. I think dereferencing the insertion 
iterator with `&**` will eventually need addressing with the move away from 
intrinsics and insertion, but that can be a matter for when the DIBuilder APIs 
get deprecated / retired.

https://github.com/llvm/llvm-project/pull/95298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Debug Info] Fix debug info ptr to ptr test (PR #95637)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/95637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Debug Info] Fix debug info ptr to ptr test (PR #95637)

[Jeremy Morse via cfe-commits]

jmorse wrote:

@huangjd Thanks for the fix -- FYI it's acceptable to commit patches like this 
without review (and leave a comment on the original PR) if you wanted to. Given 
that it's just the format of the test changing, not any of the meaning, it's an 
"obvious" fix.

https://github.com/llvm/llvm-project/pull/95637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

I think I've nailed down the source of this problem, and it's the matter to do 
with `LLVMContext::enableDebugTypeODRUniquing` that aeubanks mentioned on 
https://reviews.llvm.org/D144006. LLVM will unique DICompositeTypes via their 
ODR-name, which isn't always safe with function-local types. It's another 
circumstance where an ODR-violation that doesn't actually cause a linking error 
can instead cause debug-info to be corrupt. I don't have a reproducer that 
forces the crash found here but I can demonstrate the fundamental problem.

To reproduce, take the rebased patch from the tip of 
https://github.com/jmorse/llvm-project/tree/rebased-composite-type-fix-4 , and 
this code from llvm/test/Linker/odr-lambda-1.ll:

class Error {};
template 
void handleAllErrors(HandlerTs Handlers) {}
inline void consumeError(Error Err) {
  handleAllErrors( []() {});
}
void ArchiveMemberHeader()
{
  consumeError(Error());
}

Compile thusly:

clang input.cpp -o out1.ll -emit-llvm -S -c  -g
clang input.cpp -o out2.ll -emit-llvm -S -c  -g
vi out1.ll # Delete all LLVM function definitions to avoid linking-errors
llvm-link out1.ll out2.ll -o out3.ll -S

The link should succeed because there are no symbol conflicts. In the output IR 
in 
[out3.ll.txt](https://github.com/user-attachments/files/16354671/out3.ll.txt), 
observe that there are:
 * Two DISubprogram records for the "consumeError" function,
 * One DICompositeType for `_ZTSZ12consumeError5ErrorEUlvE_`, "`typeinfo name 
for consumeError(Error)::{lambda()#1}`"
 * The DICompositeType is the retainedNodes member of one DISubprogram, but...
 * The DICompositeType's Scope pointer is to the _other_ DISubprogram, that is 
otherwise unlinked to the rest of the metadata hierarchy.

It's this mismatch where the scope of an element in the retained nodes points 
somewhere unexpected, which causes the assertion failure reported. It's all 
because of the ODR-uniquing by type name that LLVM can do, a rationale is here:

https://github.com/llvm/llvm-project/blob/2604830aacdd563715da030d0396b565e912436f/clang/lib/CodeGen/CGDebugInfo.cpp#L1086

When DICompositeType::buildODRType de-duplicates on the basis of the type name, 
if it's a type inside a function then the scope pointer will point at the 
DISubprogram where the type was first seen. If there's an ODR violation, this 
might not be the same as the DISubprogram that is eventually selected for that 
function.

IIRC there's precedent in LLVM for throwing away lots of debug-info in the 
presence of ODR violations, but we should avoid hard errors.

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS4,PS5][Driver] Check for absent SDK when -nostdlib/-nodefaultlibs (PR #107112)

[Jeremy Morse via cfe-commits]

@@ -36,9 +35,6 @@
 // RUN: env SCE_ORBIS_SDK_DIR=.. %clang -Winvalid-or-nonexistent-directory 
-### -emit-ast -isysroot foo -target x86_64-scei-ps4 %s 2>&1 | FileCheck 
-check-prefix=WARN-ISYSROOT -check-prefix=NO-WARN %s
 // RUN: env SCE_ORBIS_SDK_DIR=.. %clang -Winvalid-or-nonexistent-directory 
-### --sysroot=foo/ -isysroot foo -target x86_64-scei-ps4 %s 2>&1 | FileCheck 
-check-prefix=WARN-ISYSROOT -check-prefix=NO-WARN %s
 
-// RUN: env SCE_ORBIS_SDK_DIR=.. %clang -Winvalid-or-nonexistent-directory 
-### -nostdlib -target x86_64-scei-ps4 %s 2>&1 | FileCheck 
-check-prefix=WARN-SYS-HEADERS -check-prefix=NO-WARN %s
-// RUN: env SCE_ORBIS_SDK_DIR=.. %clang -Winvalid-or-nonexistent-directory 
-### -nodefaultlibs -target x86_64-scei-ps4 %s 2>&1 | FileCheck 
-check-prefix=WARN-SYS-HEADERS -check-prefix=NO-WARN %s

jmorse wrote:

Just to confirm my understanding, we're intending that the library check 
occurs, testing that the diagnostic occurs should be covered by an earlier RUN 
line, thus it's correct to delete these?

The opposing view would be "we're changing the compiler-driver behaviour, so 
should positively test that it does what we want", which would mean leaving 
these RUN lines here and checking that they behave the same as without the 
flags (i.e. `--check-prefixes=WARN-SYS-HEADERS,WARN-SYS-LIBS,NO-WARN`). I lean 
slightly in this direction, @pogo59 how do you feel?

https://github.com/llvm/llvm-project/pull/107112
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [DebugInfo][RemoveDIs] Use iterator-inserters in clang (PR #102006)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse created 
https://github.com/llvm/llvm-project/pull/102006

As part of the LLVM effort to eliminate debug-info intrinsics, we're moving to 
a world where only iterators should be used to insert instructions. This isn't 
a problem in clang when instructions get generated before any debug-info is 
inserted, however we're planning on deprecating and removing the 
instruction-pointer insertion routines.

Scatter some calls to getIterator in a few places, remove a deref-then-addrof 
on another iterator, and add an overload for the createLoadInstBefore utility. 
Some callers passes a null insertion point, which we need to handle explicitly 
now.

>From cf967317327aa3971da62a15f357ee5b29268f14 Mon Sep 17 00:00:00 2001
From: Jeremy Morse 
Date: Mon, 5 Aug 2024 16:21:53 +0100
Subject: [PATCH] [DebugInfo][RemoveDIs] Use iterator-inserters in clang

As part of the LLVM effort to eliminate debug-info intrinsics, we're moving
to a world where only iterators should be used to insert instructions. This
isn't a problem in clang when instructions get generated before any
debug-info is inserted, however we're planning on deprecating and removing
the instruction-pointer insertion routines.

Scatter some calls to getIterator in a few places, remove a
deref-then-addrof on another iterator, and add an overload for the
createLoadInstBefore utility. Some callers passes a null insertion point,
which we need to handle explicitly now.
---
 clang/lib/CodeGen/CGCUDANV.cpp  |  6 +++---
 clang/lib/CodeGen/CGCall.cpp|  4 ++--
 clang/lib/CodeGen/CGCleanup.cpp | 20 ++--
 clang/lib/CodeGen/CGCoroutine.cpp   |  5 +++--
 clang/lib/CodeGen/CGExpr.cpp|  2 +-
 clang/lib/CodeGen/CGObjC.cpp|  3 ++-
 clang/lib/CodeGen/CGStmt.cpp|  2 +-
 clang/lib/CodeGen/CodeGenFunction.h |  4 ++--
 clang/lib/CodeGen/CodeGenModule.cpp | 10 +-
 9 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/clang/lib/CodeGen/CGCUDANV.cpp b/clang/lib/CodeGen/CGCUDANV.cpp
index 43dfbbb90dd52..1f5fb630a4703 100644
--- a/clang/lib/CodeGen/CGCUDANV.cpp
+++ b/clang/lib/CodeGen/CGCUDANV.cpp
@@ -505,9 +505,9 @@ static void replaceManagedVar(llvm::GlobalVariable *Var,
 }
 if (auto *I = dyn_cast(U)) {
   llvm::Value *OldV = Var;
-  llvm::Instruction *NewV =
-  new llvm::LoadInst(Var->getType(), ManagedVar, "ld.managed", false,
- llvm::Align(Var->getAlignment()), I);
+  llvm::Instruction *NewV = new llvm::LoadInst(
+  Var->getType(), ManagedVar, "ld.managed", false,
+  llvm::Align(Var->getAlignment()), I->getIterator());
   WorkItem.pop_back();
   // Replace constant expressions directly or indirectly using the managed
   // variable with instructions.
diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 2f3dd5d01fa6c..437aa7bc67dc7 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -5081,8 +5081,8 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
&CallInfo,
 llvm::AllocaInst *AI;
 if (IP) {
   IP = IP->getNextNode();
-  AI = new llvm::AllocaInst(ArgStruct, DL.getAllocaAddrSpace(),
-"argmem", IP);
+  AI = new llvm::AllocaInst(ArgStruct, DL.getAllocaAddrSpace(), "argmem",
+IP->getIterator());
 } else {
   AI = CreateTempAlloca(ArgStruct, "argmem");
 }
diff --git a/clang/lib/CodeGen/CGCleanup.cpp b/clang/lib/CodeGen/CGCleanup.cpp
index 4e210a9e3c95f..ba0632de31473 100644
--- a/clang/lib/CodeGen/CGCleanup.cpp
+++ b/clang/lib/CodeGen/CGCleanup.cpp
@@ -295,18 +295,25 @@ void EHScopeStack::Cleanup::anchor() {}
 static void createStoreInstBefore(llvm::Value *value, Address addr,
   llvm::Instruction *beforeInst,
   CodeGenFunction &CGF) {
-  auto store = new llvm::StoreInst(value, addr.emitRawPointer(CGF), 
beforeInst);
+  auto store = new llvm::StoreInst(value, addr.emitRawPointer(CGF),
+   beforeInst->getIterator());
   store->setAlignment(addr.getAlignment().getAsAlign());
 }
 
 static llvm::LoadInst *createLoadInstBefore(Address addr, const Twine &name,
-llvm::Instruction *beforeInst,
+llvm::BasicBlock::iterator 
beforeInst,
 CodeGenFunction &CGF) {
   return new llvm::LoadInst(addr.getElementType(), addr.emitRawPointer(CGF),
 name, false, addr.getAlignment().getAsAlign(),
 beforeInst);
 }
 
+static llvm::LoadInst *createLoadInstBefore(Address addr, const Twine &name,
+CodeGenFunction &CGF) {
+  return new llvm::LoadInst(addr.getElementType(), addr.emitRawPointer(CGF),
+name, false, addr.getAlignment().

[clang] [DebugInfo][RemoveDIs] Use iterator-inserters in clang (PR #102006)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse updated 
https://github.com/llvm/llvm-project/pull/102006

>From cf967317327aa3971da62a15f357ee5b29268f14 Mon Sep 17 00:00:00 2001
From: Jeremy Morse 
Date: Mon, 5 Aug 2024 16:21:53 +0100
Subject: [PATCH 1/2] [DebugInfo][RemoveDIs] Use iterator-inserters in clang

As part of the LLVM effort to eliminate debug-info intrinsics, we're moving
to a world where only iterators should be used to insert instructions. This
isn't a problem in clang when instructions get generated before any
debug-info is inserted, however we're planning on deprecating and removing
the instruction-pointer insertion routines.

Scatter some calls to getIterator in a few places, remove a
deref-then-addrof on another iterator, and add an overload for the
createLoadInstBefore utility. Some callers passes a null insertion point,
which we need to handle explicitly now.
---
 clang/lib/CodeGen/CGCUDANV.cpp  |  6 +++---
 clang/lib/CodeGen/CGCall.cpp|  4 ++--
 clang/lib/CodeGen/CGCleanup.cpp | 20 ++--
 clang/lib/CodeGen/CGCoroutine.cpp   |  5 +++--
 clang/lib/CodeGen/CGExpr.cpp|  2 +-
 clang/lib/CodeGen/CGObjC.cpp|  3 ++-
 clang/lib/CodeGen/CGStmt.cpp|  2 +-
 clang/lib/CodeGen/CodeGenFunction.h |  4 ++--
 clang/lib/CodeGen/CodeGenModule.cpp | 10 +-
 9 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/clang/lib/CodeGen/CGCUDANV.cpp b/clang/lib/CodeGen/CGCUDANV.cpp
index 43dfbbb90dd522..1f5fb630a47038 100644
--- a/clang/lib/CodeGen/CGCUDANV.cpp
+++ b/clang/lib/CodeGen/CGCUDANV.cpp
@@ -505,9 +505,9 @@ static void replaceManagedVar(llvm::GlobalVariable *Var,
 }
 if (auto *I = dyn_cast(U)) {
   llvm::Value *OldV = Var;
-  llvm::Instruction *NewV =
-  new llvm::LoadInst(Var->getType(), ManagedVar, "ld.managed", false,
- llvm::Align(Var->getAlignment()), I);
+  llvm::Instruction *NewV = new llvm::LoadInst(
+  Var->getType(), ManagedVar, "ld.managed", false,
+  llvm::Align(Var->getAlignment()), I->getIterator());
   WorkItem.pop_back();
   // Replace constant expressions directly or indirectly using the managed
   // variable with instructions.
diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 2f3dd5d01fa6c9..437aa7bc67dc7a 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -5081,8 +5081,8 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
&CallInfo,
 llvm::AllocaInst *AI;
 if (IP) {
   IP = IP->getNextNode();
-  AI = new llvm::AllocaInst(ArgStruct, DL.getAllocaAddrSpace(),
-"argmem", IP);
+  AI = new llvm::AllocaInst(ArgStruct, DL.getAllocaAddrSpace(), "argmem",
+IP->getIterator());
 } else {
   AI = CreateTempAlloca(ArgStruct, "argmem");
 }
diff --git a/clang/lib/CodeGen/CGCleanup.cpp b/clang/lib/CodeGen/CGCleanup.cpp
index 4e210a9e3c95ff..ba0632de314733 100644
--- a/clang/lib/CodeGen/CGCleanup.cpp
+++ b/clang/lib/CodeGen/CGCleanup.cpp
@@ -295,18 +295,25 @@ void EHScopeStack::Cleanup::anchor() {}
 static void createStoreInstBefore(llvm::Value *value, Address addr,
   llvm::Instruction *beforeInst,
   CodeGenFunction &CGF) {
-  auto store = new llvm::StoreInst(value, addr.emitRawPointer(CGF), 
beforeInst);
+  auto store = new llvm::StoreInst(value, addr.emitRawPointer(CGF),
+   beforeInst->getIterator());
   store->setAlignment(addr.getAlignment().getAsAlign());
 }
 
 static llvm::LoadInst *createLoadInstBefore(Address addr, const Twine &name,
-llvm::Instruction *beforeInst,
+llvm::BasicBlock::iterator 
beforeInst,
 CodeGenFunction &CGF) {
   return new llvm::LoadInst(addr.getElementType(), addr.emitRawPointer(CGF),
 name, false, addr.getAlignment().getAsAlign(),
 beforeInst);
 }
 
+static llvm::LoadInst *createLoadInstBefore(Address addr, const Twine &name,
+CodeGenFunction &CGF) {
+  return new llvm::LoadInst(addr.getElementType(), addr.emitRawPointer(CGF),
+name, false, addr.getAlignment().getAsAlign());
+}
+
 /// All the branch fixups on the EH stack have propagated out past the
 /// outermost normal cleanup; resolve them all by adding cases to the
 /// given switch instruction.
@@ -358,7 +365,7 @@ static llvm::SwitchInst 
*TransitionToCleanupSwitch(CodeGenFunction &CGF,
   if (llvm::BranchInst *Br = dyn_cast(Term)) {
 assert(Br->isUnconditional());
 auto Load = createLoadInstBefore(CGF.getNormalCleanupDestSlot(),
- "cleanup.dest", Term, CGF);
+ "cleanup.dest", Term->getIterator

[clang] [DebugInfo][RemoveDIs] Use iterator-inserters in clang (PR #102006)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse updated 
https://github.com/llvm/llvm-project/pull/102006

>From cf967317327aa3971da62a15f357ee5b29268f14 Mon Sep 17 00:00:00 2001
From: Jeremy Morse 
Date: Mon, 5 Aug 2024 16:21:53 +0100
Subject: [PATCH 1/3] [DebugInfo][RemoveDIs] Use iterator-inserters in clang

As part of the LLVM effort to eliminate debug-info intrinsics, we're moving
to a world where only iterators should be used to insert instructions. This
isn't a problem in clang when instructions get generated before any
debug-info is inserted, however we're planning on deprecating and removing
the instruction-pointer insertion routines.

Scatter some calls to getIterator in a few places, remove a
deref-then-addrof on another iterator, and add an overload for the
createLoadInstBefore utility. Some callers passes a null insertion point,
which we need to handle explicitly now.
---
 clang/lib/CodeGen/CGCUDANV.cpp  |  6 +++---
 clang/lib/CodeGen/CGCall.cpp|  4 ++--
 clang/lib/CodeGen/CGCleanup.cpp | 20 ++--
 clang/lib/CodeGen/CGCoroutine.cpp   |  5 +++--
 clang/lib/CodeGen/CGExpr.cpp|  2 +-
 clang/lib/CodeGen/CGObjC.cpp|  3 ++-
 clang/lib/CodeGen/CGStmt.cpp|  2 +-
 clang/lib/CodeGen/CodeGenFunction.h |  4 ++--
 clang/lib/CodeGen/CodeGenModule.cpp | 10 +-
 9 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/clang/lib/CodeGen/CGCUDANV.cpp b/clang/lib/CodeGen/CGCUDANV.cpp
index 43dfbbb90dd52..1f5fb630a4703 100644
--- a/clang/lib/CodeGen/CGCUDANV.cpp
+++ b/clang/lib/CodeGen/CGCUDANV.cpp
@@ -505,9 +505,9 @@ static void replaceManagedVar(llvm::GlobalVariable *Var,
 }
 if (auto *I = dyn_cast(U)) {
   llvm::Value *OldV = Var;
-  llvm::Instruction *NewV =
-  new llvm::LoadInst(Var->getType(), ManagedVar, "ld.managed", false,
- llvm::Align(Var->getAlignment()), I);
+  llvm::Instruction *NewV = new llvm::LoadInst(
+  Var->getType(), ManagedVar, "ld.managed", false,
+  llvm::Align(Var->getAlignment()), I->getIterator());
   WorkItem.pop_back();
   // Replace constant expressions directly or indirectly using the managed
   // variable with instructions.
diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 2f3dd5d01fa6c..437aa7bc67dc7 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -5081,8 +5081,8 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
&CallInfo,
 llvm::AllocaInst *AI;
 if (IP) {
   IP = IP->getNextNode();
-  AI = new llvm::AllocaInst(ArgStruct, DL.getAllocaAddrSpace(),
-"argmem", IP);
+  AI = new llvm::AllocaInst(ArgStruct, DL.getAllocaAddrSpace(), "argmem",
+IP->getIterator());
 } else {
   AI = CreateTempAlloca(ArgStruct, "argmem");
 }
diff --git a/clang/lib/CodeGen/CGCleanup.cpp b/clang/lib/CodeGen/CGCleanup.cpp
index 4e210a9e3c95f..ba0632de31473 100644
--- a/clang/lib/CodeGen/CGCleanup.cpp
+++ b/clang/lib/CodeGen/CGCleanup.cpp
@@ -295,18 +295,25 @@ void EHScopeStack::Cleanup::anchor() {}
 static void createStoreInstBefore(llvm::Value *value, Address addr,
   llvm::Instruction *beforeInst,
   CodeGenFunction &CGF) {
-  auto store = new llvm::StoreInst(value, addr.emitRawPointer(CGF), 
beforeInst);
+  auto store = new llvm::StoreInst(value, addr.emitRawPointer(CGF),
+   beforeInst->getIterator());
   store->setAlignment(addr.getAlignment().getAsAlign());
 }
 
 static llvm::LoadInst *createLoadInstBefore(Address addr, const Twine &name,
-llvm::Instruction *beforeInst,
+llvm::BasicBlock::iterator 
beforeInst,
 CodeGenFunction &CGF) {
   return new llvm::LoadInst(addr.getElementType(), addr.emitRawPointer(CGF),
 name, false, addr.getAlignment().getAsAlign(),
 beforeInst);
 }
 
+static llvm::LoadInst *createLoadInstBefore(Address addr, const Twine &name,
+CodeGenFunction &CGF) {
+  return new llvm::LoadInst(addr.getElementType(), addr.emitRawPointer(CGF),
+name, false, addr.getAlignment().getAsAlign());
+}
+
 /// All the branch fixups on the EH stack have propagated out past the
 /// outermost normal cleanup; resolve them all by adding cases to the
 /// given switch instruction.
@@ -358,7 +365,7 @@ static llvm::SwitchInst 
*TransitionToCleanupSwitch(CodeGenFunction &CGF,
   if (llvm::BranchInst *Br = dyn_cast(Term)) {
 assert(Br->isUnconditional());
 auto Load = createLoadInstBefore(CGF.getNormalCleanupDestSlot(),
- "cleanup.dest", Term, CGF);
+ "cleanup.dest", Term->getIterator(), CG

[clang] 3c9bcf0 - [Clang][Coroutine][DebugInfo] Relax test ordering requirement

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2021-04-26T10:07:22+01:00
New Revision: 3c9bcf0e3549d89b31e19e67a5a16babdee2c72d

URL: 
https://github.com/llvm/llvm-project/commit/3c9bcf0e3549d89b31e19e67a5a16babdee2c72d
DIFF: 
https://github.com/llvm/llvm-project/commit/3c9bcf0e3549d89b31e19e67a5a16babdee2c72d.diff

LOG: [Clang][Coroutine][DebugInfo] Relax test ordering requirement

The test added in D97533 (and modified by this patch) has some overly
strict printed metadata ordering requirements, specifically the
interleaving of DILocalVariable nodes and DILocation nodes. Slight changes
in metadata emission can easily break this unfortunately.

This patch stops after clang codegen rather than allowing the coro splitter
to run,  and reduces the need for ordering: it picks out the
DILocalVariable nodes being sought, in any order (CHECK-DAG), and doesn't
examine any DILocations. The implicit CHECK-NOT is what's important: the
test seeks to ensure a duplicate set of DILocalVariables aren't emitted in
the same scope.

Differential Revision: https://reviews.llvm.org/D100298

Added: 


Modified: 
clang/test/CodeGenCoroutines/coro-dwarf.cpp

Removed: 




diff  --git a/clang/test/CodeGenCoroutines/coro-dwarf.cpp 
b/clang/test/CodeGenCoroutines/coro-dwarf.cpp
index eacbd5b39d2a..391d37d23c0d 100644
--- a/clang/test/CodeGenCoroutines/coro-dwarf.cpp
+++ b/clang/test/CodeGenCoroutines/coro-dwarf.cpp
@@ -1,4 +1,7 @@
-// RUN: %clang_cc1 -std=c++2a -fcoroutines-ts -triple=x86_64 -dwarf-version=4 
-debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -disable-llvm-optzns -std=c++2a -fcoroutines-ts \
+// RUN:-triple=x86_64 -dwarf-version=4 -debug-info-kind=limited \
+// RUN:-emit-llvm -o - %s | \
+// RUN:FileCheck %s --implicit-check-not=DILocalVariable
 
 namespace std::experimental {
 template  struct coroutine_traits;
@@ -63,15 +66,7 @@ void f_coro(int val, MoveOnly moParam, MoveAndCopy mcParam) {
 }
 
 // CHECK: ![[SP:[0-9]+]] = distinct !DISubprogram(name: "f_coro", linkageName: 
"_Z6f_coroi8MoveOnly11MoveAndCopy"
-// CHECK: !{{[0-9]+}} = !DILocalVariable(name: "val", arg: 1, scope: ![[SP]], 
file: !8, line: 60, type: !{{[0-9]+}})
-// CHECK: !{{[0-9]+}} = !DILocation(line: 60, column: 17, scope: ![[SP]])
-// CHECK: !{{[0-9]+}} = !DILocalVariable(name: "moParam", arg: 2, scope: 
![[SP]], file: !8, line: 60, type: !{{[0-9]+}})
-// CHECK: !{{[0-9]+}} = !DILocation(line: 60, column: 31, scope: ![[SP]])
-// CHECK: !{{[0-9]+}} = !DILocalVariable(name: "mcParam", arg: 3, scope: 
![[SP]], file: !8, line: 60, type: !{{[0-9]+}})
-// CHECK: !{{[0-9]+}} = !DILocation(line: 60, column: 52, scope: ![[SP]])
-// CHECK: !{{[0-9]+}} = !DILocation(line: 60, column: 61, scope: ![[SP]])
-// CHECK: !{{[0-9]+}} = !DILocation(line: 60, column: 6, scope: ![[SP]])
-// CHECK: !{{[0-9]+}} = !DILocation(line: 0, scope: ![[SP]])
-// CHECK-NOT: !{{[0-9]+}} = !DILocalVariable(name: "val", scope: ![[SP]], 
type: !{{[0-9]+}}, flags: DIFlagArtificial)
-// CHECK-NOT: !{{[0-9]+}} = !DILocalVariable(name: "moParam", scope: ![[SP]], 
type: !{{[0-9]+}}, flags: DIFlagArtificial)
-// CHECK-NOT:: !{{[0-9]+}} = !DILocalVariable(name: "mcParam", scope: ![[SP]], 
type: !{{[0-9]+}}, flags: DIFlagArtificial)
+// CHECK: !{{[0-9]+}} = !DILocalVariable(name: "val", arg: 1, scope: ![[SP]], 
file: !8, line: {{[0-9]+}}, type: !{{[0-9]+}})
+// CHECK: !{{[0-9]+}} = !DILocalVariable(name: "moParam", arg: 2, scope: 
![[SP]], file: !8, line: {{[0-9]+}}, type: !{{[0-9]+}})
+// CHECK: !{{[0-9]+}} = !DILocalVariable(name: "mcParam", arg: 3, scope: 
![[SP]], file: !8, line: {{[0-9]+}}, type: !{{[0-9]+}})
+// CHECK: !{{[0-9]+}} = !DILocalVariable(name: "__promise",



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ea22fdd - [Clang][DebugInfo] Cease turning instruction-referencing off by default

[Jeremy Morse via cfe-commits]

Author: Jeremy Morse
Date: 2021-12-22T16:30:05Z
New Revision: ea22fdd120aeb1bbb9ea96670d70193dc02b2c5f

URL: 
https://github.com/llvm/llvm-project/commit/ea22fdd120aeb1bbb9ea96670d70193dc02b2c5f
DIFF: 
https://github.com/llvm/llvm-project/commit/ea22fdd120aeb1bbb9ea96670d70193dc02b2c5f.diff

LOG: [Clang][DebugInfo] Cease turning instruction-referencing off by default

Over in D114631 I turned this debug-info feature on by default, for x86_64
only. I'd previously stripped out the clang cc1 option that controlled it
in 651122fc4ac, unfortunately that turned out to not be completely
effective, and the two things deleted in this patch continued to keep it
off-by-default.  Oooff.

As a follow-up, this patch removes the last few things to do with
ValueTrackingVariableLocations from clang, which was the original purpose
of D114631. In an ideal world, if this patch causes you trouble you'd
revert 3c045070882f instead, which was where this behaviour was supposed
to start being the default, although that might not be practical any more.

Added: 


Modified: 
clang/include/clang/Basic/CodeGenOptions.def
clang/lib/CodeGen/BackendUtil.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index 94b3003a9c33c..723302f108e20 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -368,9 +368,6 @@ ENUM_CODEGENOPT(DebuggerTuning, llvm::DebuggerKind, 3,
 /// emitted.
 VALUE_CODEGENOPT(DwarfVersion, 3, 0)
 
-/// Whether to use experimental new variable location tracking.
-CODEGENOPT(ValueTrackingVariableLocations, 1, 0)
-
 /// Whether we should emit CodeView debug information. It's possible to emit
 /// CodeView and DWARF into the same object.
 CODEGENOPT(EmitCodeView, 1, 0)

diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 5e16d3525b383..bacac0a20d4d5 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -603,8 +603,6 @@ static bool initTargetOptions(DiagnosticsEngine &Diags,
   Options.ForceDwarfFrameSection = CodeGenOpts.ForceDwarfFrameSection;
   Options.EmitCallSiteInfo = CodeGenOpts.EmitCallSiteInfo;
   Options.EnableAIXExtendedAltivecABI = 
CodeGenOpts.EnableAIXExtendedAltivecABI;
-  Options.ValueTrackingVariableLocations =
-  CodeGenOpts.ValueTrackingVariableLocations;
   Options.XRayOmitFunctionIndex = CodeGenOpts.XRayOmitFunctionIndex;
   Options.LoopAlignment = CodeGenOpts.LoopAlignment;
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] ea22fdd - [Clang][DebugInfo] Cease turning instruction-referencing off by default

[Jeremy Morse via cfe-commits]

On Wed, Dec 22, 2021 at 4:34 PM David Blaikie via cfe-commits
 wrote:
> Is there a way to turn this off now, if it's broken for some user/use case? I 
> guess using an -mllvm flag, instead of an -Xclang flag?

Yup, that should be achieved by "-mllvm
-experimental-debug-variable-locations=false", there's a test for that
in llvm/test/DebugInfo/X86/instr-ref-flag.ll.

> Generally I think for a significant change like this the process would be to 
> add it under a flag, off by default, encourage people to test it by opting in 
> via the flag, eventually change the default for the flag (letting people know 
> they can opt-out using the flag if they see problems & to report them to you 
> so they can be fixed & hopefully they can stop opting out) & then remove the 
> flag when it's stable. Reverting a patch to disable a newly-on-by-default 
> feature is a bit heavyweight and it can be nice to have a flag to control it 
> while it's getting more exposure/experience.

Indeed, I'd hoped this was largely achieved with
https://lists.llvm.org/pipermail/llvm-dev/2021-July/151965.html , I
guess what's missing is better communicating in how to opt out now,
alas. It's unfortunate that people bisecting back are going to find
this commit; I couldn't think of another way of rectifying things
without pushing up several reverts and the re-applies at the same time
though.

--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [NFC] Replace more DenseMaps with SmallDenseMaps (PR #111836)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse created 
https://github.com/llvm/llvm-project/pull/111836

These DenseMaps all appear as some of the most frequent sources of 
memory-allocations that could otherwise be accomodated with an initial stack 
allocation. For simplicity, I've typedef'd one map-type to be BlockColorMapT, 
used by various block colouring functions.

This also features one opportunistic replacement of std::vector with 
SmallVector, as it's in a path that obviously always allocates.

Compared to the other patches reducing DenseMap allocations the benefits from 
this one are quite small -- I've reached the point of diminishing returns: 
https://llvm-compile-time-tracker.com/compare.php?from=c7fbcae72557cbe14bca615038254649c1177401&to=0785a8d0fd31541d6a8af616111312780e268611&stat=instructions:u

>From d2b935e3a537e065b00f543a1792d1979ba413d9 Mon Sep 17 00:00:00 2001
From: Jeremy Morse 
Date: Thu, 10 Oct 2024 14:17:34 +0100
Subject: [PATCH] [NFC] Replace more DenseMaps with SmallDenseMaps

These DenseMaps all appear as some of the most frequent sources of
memory-allocations that could otherwise be accomodated with an initial
stack allocation. For simplicity, I've typedef'd one map-type to be
BlockColorMapT, used by various block colouring functions.

This also features one opportunistic replacement of std::vector with
SmallVector, as it's in a path that obviously always allocates.
---
 clang/include/clang/AST/CXXInheritance.h   |  2 +-
 clang/lib/AST/ItaniumMangle.cpp|  4 ++--
 llvm/include/llvm/ADT/SCCIterator.h|  2 +-
 llvm/include/llvm/Analysis/ConstraintSystem.h  |  8 
 llvm/include/llvm/Analysis/DominanceFrontier.h |  4 ++--
 llvm/include/llvm/Analysis/DominanceFrontierImpl.h |  2 +-
 llvm/include/llvm/Analysis/LoopIterator.h  |  8 
 llvm/include/llvm/Analysis/MemorySSA.h |  4 ++--
 llvm/include/llvm/Analysis/MustExecute.h   |  4 ++--
 llvm/include/llvm/IR/EHPersonalities.h |  3 ++-
 llvm/include/llvm/IR/PredIteratorCache.h   |  2 +-
 llvm/include/llvm/Transforms/Utils/Cloning.h   |  2 +-
 llvm/include/llvm/Transforms/Utils/SSAUpdaterImpl.h|  2 +-
 llvm/lib/Analysis/InlineCost.cpp   |  2 +-
 llvm/lib/Analysis/LazyValueInfo.cpp|  2 +-
 llvm/lib/Analysis/MustExecute.cpp  |  2 +-
 llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp |  2 +-
 llvm/lib/CodeGen/MachineSSAUpdater.cpp |  2 +-
 llvm/lib/CodeGen/WinEHPrepare.cpp  |  4 ++--
 llvm/lib/IR/EHPersonalities.cpp|  4 ++--
 llvm/lib/IR/Verifier.cpp   |  2 +-
 llvm/lib/Target/X86/X86WinEHState.cpp  | 10 +-
 .../Transforms/InstCombine/InstructionCombining.cpp|  2 +-
 .../Transforms/Instrumentation/AddressSanitizer.cpp|  2 +-
 .../Transforms/Instrumentation/PGOInstrumentation.cpp  |  4 ++--
 llvm/lib/Transforms/ObjCARC/ObjCARC.cpp|  6 +++---
 llvm/lib/Transforms/ObjCARC/ObjCARC.h  |  4 ++--
 llvm/lib/Transforms/ObjCARC/ObjCARCContract.cpp| 10 +-
 llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp|  2 +-
 llvm/lib/Transforms/Scalar/ConstraintElimination.cpp   |  6 +++---
 llvm/lib/Transforms/Scalar/Reassociate.cpp |  2 +-
 llvm/lib/Transforms/Utils/SSAUpdater.cpp   |  2 +-
 32 files changed, 59 insertions(+), 58 deletions(-)

diff --git a/clang/include/clang/AST/CXXInheritance.h 
b/clang/include/clang/AST/CXXInheritance.h
index bbef01843e0b0a..b9057e15a41988 100644
--- a/clang/include/clang/AST/CXXInheritance.h
+++ b/clang/include/clang/AST/CXXInheritance.h
@@ -268,7 +268,7 @@ struct UniqueVirtualMethod {
 /// subobject in which that virtual function occurs).
 class OverridingMethods {
   using ValuesT = SmallVector;
-  using MapType = llvm::MapVector;
+  using MapType = llvm::SmallMapVector;
 
   MapType Overrides;
 
diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 777cdca1a0c0d7..0ec0855cf52440 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -392,8 +392,8 @@ class CXXNameMangler {
   AbiTagState *AbiTags = nullptr;
   AbiTagState AbiTagsRoot;
 
-  llvm::DenseMap Substitutions;
-  llvm::DenseMap ModuleSubstitutions;
+  llvm::SmallDenseMap Substitutions;
+  llvm::SmallDenseMap ModuleSubstitutions;
 
   ASTContext &getASTContext() const { return Context.getASTContext(); }
 
diff --git a/llvm/include/llvm/ADT/SCCIterator.h 
b/llvm/include/llvm/ADT/SCCIterator.h
index 3bd103c13f19f9..a35e0a3f8e8c95 100644
--- a/llvm/include/llvm/ADT/SCCIterator.h
+++ b/llvm/include/llvm/ADT/SCCIterator.h
@@ -73,7 +73,7 @@ class scc_iterator : public iterator_facade_base<
   ///
   /// nodeVisitNumbers are per-node visit numbers, also used as DFS flags.
   unsigned visitNum;
-  DenseM

[clang] [llvm] [NFC] Replace more DenseMaps with SmallDenseMaps (PR #111836)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse updated 
https://github.com/llvm/llvm-project/pull/111836

>From d2b935e3a537e065b00f543a1792d1979ba413d9 Mon Sep 17 00:00:00 2001
From: Jeremy Morse 
Date: Thu, 10 Oct 2024 14:17:34 +0100
Subject: [PATCH 1/2] [NFC] Replace more DenseMaps with SmallDenseMaps

These DenseMaps all appear as some of the most frequent sources of
memory-allocations that could otherwise be accomodated with an initial
stack allocation. For simplicity, I've typedef'd one map-type to be
BlockColorMapT, used by various block colouring functions.

This also features one opportunistic replacement of std::vector with
SmallVector, as it's in a path that obviously always allocates.
---
 clang/include/clang/AST/CXXInheritance.h   |  2 +-
 clang/lib/AST/ItaniumMangle.cpp|  4 ++--
 llvm/include/llvm/ADT/SCCIterator.h|  2 +-
 llvm/include/llvm/Analysis/ConstraintSystem.h  |  8 
 llvm/include/llvm/Analysis/DominanceFrontier.h |  4 ++--
 llvm/include/llvm/Analysis/DominanceFrontierImpl.h |  2 +-
 llvm/include/llvm/Analysis/LoopIterator.h  |  8 
 llvm/include/llvm/Analysis/MemorySSA.h |  4 ++--
 llvm/include/llvm/Analysis/MustExecute.h   |  4 ++--
 llvm/include/llvm/IR/EHPersonalities.h |  3 ++-
 llvm/include/llvm/IR/PredIteratorCache.h   |  2 +-
 llvm/include/llvm/Transforms/Utils/Cloning.h   |  2 +-
 llvm/include/llvm/Transforms/Utils/SSAUpdaterImpl.h|  2 +-
 llvm/lib/Analysis/InlineCost.cpp   |  2 +-
 llvm/lib/Analysis/LazyValueInfo.cpp|  2 +-
 llvm/lib/Analysis/MustExecute.cpp  |  2 +-
 llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp |  2 +-
 llvm/lib/CodeGen/MachineSSAUpdater.cpp |  2 +-
 llvm/lib/CodeGen/WinEHPrepare.cpp  |  4 ++--
 llvm/lib/IR/EHPersonalities.cpp|  4 ++--
 llvm/lib/IR/Verifier.cpp   |  2 +-
 llvm/lib/Target/X86/X86WinEHState.cpp  | 10 +-
 .../Transforms/InstCombine/InstructionCombining.cpp|  2 +-
 .../Transforms/Instrumentation/AddressSanitizer.cpp|  2 +-
 .../Transforms/Instrumentation/PGOInstrumentation.cpp  |  4 ++--
 llvm/lib/Transforms/ObjCARC/ObjCARC.cpp|  6 +++---
 llvm/lib/Transforms/ObjCARC/ObjCARC.h  |  4 ++--
 llvm/lib/Transforms/ObjCARC/ObjCARCContract.cpp| 10 +-
 llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp|  2 +-
 llvm/lib/Transforms/Scalar/ConstraintElimination.cpp   |  6 +++---
 llvm/lib/Transforms/Scalar/Reassociate.cpp |  2 +-
 llvm/lib/Transforms/Utils/SSAUpdater.cpp   |  2 +-
 32 files changed, 59 insertions(+), 58 deletions(-)

diff --git a/clang/include/clang/AST/CXXInheritance.h 
b/clang/include/clang/AST/CXXInheritance.h
index bbef01843e0b0a..b9057e15a41988 100644
--- a/clang/include/clang/AST/CXXInheritance.h
+++ b/clang/include/clang/AST/CXXInheritance.h
@@ -268,7 +268,7 @@ struct UniqueVirtualMethod {
 /// subobject in which that virtual function occurs).
 class OverridingMethods {
   using ValuesT = SmallVector;
-  using MapType = llvm::MapVector;
+  using MapType = llvm::SmallMapVector;
 
   MapType Overrides;
 
diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 777cdca1a0c0d7..0ec0855cf52440 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -392,8 +392,8 @@ class CXXNameMangler {
   AbiTagState *AbiTags = nullptr;
   AbiTagState AbiTagsRoot;
 
-  llvm::DenseMap Substitutions;
-  llvm::DenseMap ModuleSubstitutions;
+  llvm::SmallDenseMap Substitutions;
+  llvm::SmallDenseMap ModuleSubstitutions;
 
   ASTContext &getASTContext() const { return Context.getASTContext(); }
 
diff --git a/llvm/include/llvm/ADT/SCCIterator.h 
b/llvm/include/llvm/ADT/SCCIterator.h
index 3bd103c13f19f9..a35e0a3f8e8c95 100644
--- a/llvm/include/llvm/ADT/SCCIterator.h
+++ b/llvm/include/llvm/ADT/SCCIterator.h
@@ -73,7 +73,7 @@ class scc_iterator : public iterator_facade_base<
   ///
   /// nodeVisitNumbers are per-node visit numbers, also used as DFS flags.
   unsigned visitNum;
-  DenseMap nodeVisitNumbers;
+  SmallDenseMap nodeVisitNumbers;
 
   /// Stack holding nodes of the SCC.
   std::vector SCCNodeStack;
diff --git a/llvm/include/llvm/Analysis/ConstraintSystem.h 
b/llvm/include/llvm/Analysis/ConstraintSystem.h
index 449852343964ca..2ac0fc1ddc06c3 100644
--- a/llvm/include/llvm/Analysis/ConstraintSystem.h
+++ b/llvm/include/llvm/Analysis/ConstraintSystem.h
@@ -51,7 +51,7 @@ class ConstraintSystem {
 
   /// A map of variables (IR values) to their corresponding index in the
   /// constraint system.
-  DenseMap Value2Index;
+  SmallDenseMap Value2Index;
 
   // Eliminate constraints from the system using Fourier–Motzkin elimination.
   bool eliminateUsingFM();
@@ -70,7 +70,7 @@ class C

[clang] [llvm] [NFC] Replace more DenseMaps with SmallDenseMaps (PR #111836)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Undid the format-changes in this PR. For context: I've been building profiles 
of all DenseMap allocations across a build of the CTMark suite to find 
DenseMaps that a) are frequently used and b) usually have a small number of 
elements, making them good candidates for initial stack allocations. This patch 
one of the results of that profile-building, the touched DenseMaps are all 
reasonably frequently used, and using SmallDenseMap yields a small compile-time 
improvement.

https://github.com/llvm/llvm-project/pull/111836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [NFC] Replace more DenseMaps with SmallDenseMaps (PR #111836)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse updated 
https://github.com/llvm/llvm-project/pull/111836

>From d2b935e3a537e065b00f543a1792d1979ba413d9 Mon Sep 17 00:00:00 2001
From: Jeremy Morse 
Date: Thu, 10 Oct 2024 14:17:34 +0100
Subject: [PATCH 1/3] [NFC] Replace more DenseMaps with SmallDenseMaps

These DenseMaps all appear as some of the most frequent sources of
memory-allocations that could otherwise be accomodated with an initial
stack allocation. For simplicity, I've typedef'd one map-type to be
BlockColorMapT, used by various block colouring functions.

This also features one opportunistic replacement of std::vector with
SmallVector, as it's in a path that obviously always allocates.
---
 clang/include/clang/AST/CXXInheritance.h   |  2 +-
 clang/lib/AST/ItaniumMangle.cpp|  4 ++--
 llvm/include/llvm/ADT/SCCIterator.h|  2 +-
 llvm/include/llvm/Analysis/ConstraintSystem.h  |  8 
 llvm/include/llvm/Analysis/DominanceFrontier.h |  4 ++--
 llvm/include/llvm/Analysis/DominanceFrontierImpl.h |  2 +-
 llvm/include/llvm/Analysis/LoopIterator.h  |  8 
 llvm/include/llvm/Analysis/MemorySSA.h |  4 ++--
 llvm/include/llvm/Analysis/MustExecute.h   |  4 ++--
 llvm/include/llvm/IR/EHPersonalities.h |  3 ++-
 llvm/include/llvm/IR/PredIteratorCache.h   |  2 +-
 llvm/include/llvm/Transforms/Utils/Cloning.h   |  2 +-
 llvm/include/llvm/Transforms/Utils/SSAUpdaterImpl.h|  2 +-
 llvm/lib/Analysis/InlineCost.cpp   |  2 +-
 llvm/lib/Analysis/LazyValueInfo.cpp|  2 +-
 llvm/lib/Analysis/MustExecute.cpp  |  2 +-
 llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp |  2 +-
 llvm/lib/CodeGen/MachineSSAUpdater.cpp |  2 +-
 llvm/lib/CodeGen/WinEHPrepare.cpp  |  4 ++--
 llvm/lib/IR/EHPersonalities.cpp|  4 ++--
 llvm/lib/IR/Verifier.cpp   |  2 +-
 llvm/lib/Target/X86/X86WinEHState.cpp  | 10 +-
 .../Transforms/InstCombine/InstructionCombining.cpp|  2 +-
 .../Transforms/Instrumentation/AddressSanitizer.cpp|  2 +-
 .../Transforms/Instrumentation/PGOInstrumentation.cpp  |  4 ++--
 llvm/lib/Transforms/ObjCARC/ObjCARC.cpp|  6 +++---
 llvm/lib/Transforms/ObjCARC/ObjCARC.h  |  4 ++--
 llvm/lib/Transforms/ObjCARC/ObjCARCContract.cpp| 10 +-
 llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp|  2 +-
 llvm/lib/Transforms/Scalar/ConstraintElimination.cpp   |  6 +++---
 llvm/lib/Transforms/Scalar/Reassociate.cpp |  2 +-
 llvm/lib/Transforms/Utils/SSAUpdater.cpp   |  2 +-
 32 files changed, 59 insertions(+), 58 deletions(-)

diff --git a/clang/include/clang/AST/CXXInheritance.h 
b/clang/include/clang/AST/CXXInheritance.h
index bbef01843e0b0a..b9057e15a41988 100644
--- a/clang/include/clang/AST/CXXInheritance.h
+++ b/clang/include/clang/AST/CXXInheritance.h
@@ -268,7 +268,7 @@ struct UniqueVirtualMethod {
 /// subobject in which that virtual function occurs).
 class OverridingMethods {
   using ValuesT = SmallVector;
-  using MapType = llvm::MapVector;
+  using MapType = llvm::SmallMapVector;
 
   MapType Overrides;
 
diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 777cdca1a0c0d7..0ec0855cf52440 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -392,8 +392,8 @@ class CXXNameMangler {
   AbiTagState *AbiTags = nullptr;
   AbiTagState AbiTagsRoot;
 
-  llvm::DenseMap Substitutions;
-  llvm::DenseMap ModuleSubstitutions;
+  llvm::SmallDenseMap Substitutions;
+  llvm::SmallDenseMap ModuleSubstitutions;
 
   ASTContext &getASTContext() const { return Context.getASTContext(); }
 
diff --git a/llvm/include/llvm/ADT/SCCIterator.h 
b/llvm/include/llvm/ADT/SCCIterator.h
index 3bd103c13f19f9..a35e0a3f8e8c95 100644
--- a/llvm/include/llvm/ADT/SCCIterator.h
+++ b/llvm/include/llvm/ADT/SCCIterator.h
@@ -73,7 +73,7 @@ class scc_iterator : public iterator_facade_base<
   ///
   /// nodeVisitNumbers are per-node visit numbers, also used as DFS flags.
   unsigned visitNum;
-  DenseMap nodeVisitNumbers;
+  SmallDenseMap nodeVisitNumbers;
 
   /// Stack holding nodes of the SCC.
   std::vector SCCNodeStack;
diff --git a/llvm/include/llvm/Analysis/ConstraintSystem.h 
b/llvm/include/llvm/Analysis/ConstraintSystem.h
index 449852343964ca..2ac0fc1ddc06c3 100644
--- a/llvm/include/llvm/Analysis/ConstraintSystem.h
+++ b/llvm/include/llvm/Analysis/ConstraintSystem.h
@@ -51,7 +51,7 @@ class ConstraintSystem {
 
   /// A map of variables (IR values) to their corresponding index in the
   /// constraint system.
-  DenseMap Value2Index;
+  SmallDenseMap Value2Index;
 
   // Eliminate constraints from the system using Fourier–Motzkin elimination.
   bool eliminateUsingFM();
@@ -70,7 +70,7 @@ class C

[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Hadn't realised lambda types will pop up everywhere, the cost might be too 
high. I'll test with building clang and our internal codebases to see if the 
fix works and what the cost is.

> Surely if we can compute a unique mangled name for this local class, we 
> should use it as the identifier and merge it.

Indeed, it's not the ODR-uniquing per-se that's causing the trouble here, it's 
the fact that we do not merge together the DISubprograms that are the 
containing scope for that type upon module linking. I'm not familiar with the 
design decisions behind that, but a courtesy glance suggests it's important to 
identify the compilation unit that a DISubprogram instance came from. We're 
then stuck with multiple DISubprograms and a single DIComposite type referring 
to one of them as being its scope, which presumably breaks a lot of assumptions.

Perhaps a worthwhile direction is separating DISubprograms into abstract and 
definition portions, much like DWARF does, which would allow us to put these 
types into the declaration and have a well defined scope hierarchy: types that 
get uniqued refer to the abstract-DISubprogram for their lexical scope. Perhaps 
that's can be achieved with the existing distinction between definition 
DISubprograms and "declaration" DISubprograms? A quick survey of callers to 
`DISubprogram::getDefinition` and `isDefinition` indicates there aren't many 
decisions made throughout LLVM based on the definition/declaration split, and 
there are comments in LLVMContextImpl.h suggesting declaration-DISubprograms 
are used in ODR'd types too.

If we took that route, the scope-chain would still become a tree of scopes 
instead of distinct chains, and we would still need to fix the problem of 
CodeGen LexicalScopes encountering the abstract/declaration DISubprogram. 
However, I think we'd have the reasonable solution of mapping 
declaration-DISubprograms in a function to their definition-DISubprogram 
(assuming the definition had been found already), which is much more reliable 
than seeking a DISubprogram by name or something.

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [X86] Don't request 0x90 nop filling in p2align directives (PR #110134)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse closed 
https://github.com/llvm/llvm-project/pull/110134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Pass default -z options to PS5 linker (PR #113162)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/113162
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Update default linking options when `-r` omitted. (PR #113595)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/113595
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Supply default linker scripts (PR #114546)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/114546
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Pass `-z rodynamic` to the linker (PR #115009)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/115009
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Supply libraries and CRT objects to the linker (PR #115497)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

> I don't find its current state especially offensive, but I could have a go at 
> moving the new stuff to some helper functions, perhaps?

If it's manageable then it's manageable, 

> I have a very slight preference to revert this particular commit as I feel 
> there's slightly more chance for error now, though I did validate with some 
> experiments. Let me know what you think.

Yeah, while there might be slightly more coverage it comes at the cost of 
considerable uglyness, so backing that out sounds is preferable to me too.

Does the flipped order of library-option-names in 100c3c271 have an actual 
effect on behaviour? Just curious.

LGTM

https://github.com/llvm/llvm-project/pull/115497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Allow `-T` to override `--default-script` (PR #116074)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/116074
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Pass a target emulation to the linker (PR #114060)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/114060
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Supply libraries and CRT objects to the linker (PR #115497)

[Jeremy Morse via cfe-commits]

@@ -97,6 +97,60 @@
 // Check the default library name.
 // CHECK-JMC: "--push-state" "--whole-archive" "-lSceJmc_nosubmission" 
"--pop-state"
 
+// Test that CRT objects and libraries are supplied to the linker and can be
+// omitted with -noxxx options. These switches have some interaction with
+// sanitizer RT libraries. That's checked in fsanitize.c
+
+// RUN: %clang --target=x86_64-sie-ps5 %s -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-MAIN-CRT,CHECK-DYNAMIC-LIBC,CHECK-DYNAMIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -shared -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-SHARED-CRT,CHECK-DYNAMIC-LIBC,CHECK-DYNAMIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -static -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-STATIC-CRT,CHECK-STATIC-LIBCPP,CHECK-STATIC-LIBC,CHECK-STATIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -r -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-NO-CRT,CHECK-NO-LIBS %s
+
+// RUN: %clang --target=x86_64-sie-ps5 %s -pthread -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-PTHREAD %s
+
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostartfiles -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-NO-CRT,CHECK-DYNAMIC-LIBC,CHECK-DYNAMIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostartfiles -shared -### 2>&1 | 
FileCheck 
--check-prefixes=CHECK-LD,CHECK-NO-CRT,CHECK-DYNAMIC-LIBC,CHECK-DYNAMIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostartfiles -static -### 2>&1 | 
FileCheck 
--check-prefixes=CHECK-LD,CHECK-NO-CRT,CHECK-STATIC-LIBCPP,CHECK-STATIC-LIBC,CHECK-STATIC-CORE-LIBS
 %s
+
+// RUN: %clang --target=x86_64-sie-ps5 %s -nodefaultlibs -pthread -fjmc -### 
2>&1 | FileCheck --check-prefixes=CHECK-LD,CHECK-MAIN-CRT,CHECK-NO-LIBS %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nodefaultlibs -pthread -fjmc 
-shared -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-SHARED-CRT,CHECK-NO-LIBS %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nodefaultlibs -pthread -fjmc 
-static -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-STATIC-CRT,CHECK-NO-LIBS %s
+
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostdlib -pthread -fjmc -### 2>&1 | 
FileCheck --check-prefixes=CHECK-LD,CHECK-NO-CRT,CHECK-NO-LIBS %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostdlib -pthread -fjmc -shared 
-### 2>&1 | FileCheck --check-prefixes=CHECK-LD,CHECK-NO-CRT,CHECK-NO-LIBS %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostdlib -pthread -fjmc -static 
-### 2>&1 | FileCheck --check-prefixes=CHECK-LD,CHECK-NO-CRT,CHECK-NO-LIBS %s
+
+// RUN: %clang --target=x86_64-sie-ps5 %s -nolibc -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-MAIN-CRT,CHECK-NO-LIBC,CHECK-DYNAMIC-CORE-LIBS 
%s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nolibc -shared -### 2>&1 | 
FileCheck 
--check-prefixes=CHECK-LD,CHECK-SHARED-CRT,CHECK-NO-LIBC,CHECK-DYNAMIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nolibc -static -### 2>&1 | 
FileCheck 
--check-prefixes=CHECK-LD,CHECK-STATIC-CRT,CHECK-STATIC-LIBCPP,CHECK-NO-LIBC,CHECK-STATIC-CORE-LIBS
 %s
+
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostdlib++ -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LD,CHECK-MAIN-CRT,CHECK-NO-LIBCPP,CHECK-DYNAMIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostdlib++ -shared -### 2>&1 | 
FileCheck 
--check-prefixes=CHECK-LD,CHECK-SHARED-CRT,CHECK-NO-LIBCPP,CHECK-DYNAMIC-CORE-LIBS
 %s
+// RUN: %clang --target=x86_64-sie-ps5 %s -nostdlib++ -static -### 2>&1 | 
FileCheck 
--check-prefixes=CHECK-LD,CHECK-STATIC-CRT,CHECK-NO-LIBCPP,CHECK-STATIC-LIBC,CHECK-STATIC-CORE-LIBS
 %s
+
+// CHECK-LD: {{ld(\.exe)?}}"
+// CHECK-MAIN-CRT-SAME: "crt1.o" "crti.o" "crtbegin.o"
+// CHECK-SHARED-CRT-SAME: "crti.o" "crtbeginS.o"
+// CHECK-STATIC-CRT-SAMW: "crt1.o" "crti.o" "crtbeginT.o"

jmorse wrote:

-SAME

https://github.com/llvm/llvm-project/pull/115497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Supply libraries and CRT objects to the linker (PR #115497)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse edited 
https://github.com/llvm/llvm-project/pull/115497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Supply libraries and CRT objects to the linker (PR #115497)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse commented:

Just to check my understanding, things like CHECK-MAIN-CRT-SAME are going to 
shift the match-position that FileCheck is looking at forwards, so that we have 
to match in the correct order, yes?

I get the feeling that given how much of the construct-a-job logic filters for 
`!Relocatable` it might be worth having that as an early exit. On the other 
hand, the logic here is already a complicated matrix of expectations, no need 
to make it more complicated in the name of lines-of-code.

For the CHECK-NO... flavour of checklines, would they be better as 
`--check-implicit-not` arguments to FileCheck, or is it alright to rely on them 
being in a rigid order? (No strong opinion).

https://github.com/llvm/llvm-project/pull/115497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

[This keeps on slipping to the back of my TODO list,]

I've been enlightened by the comments on #68929 about ODR rules, and that there 
isn't a violation in the example; it does at least exercise the code path of 
interest, my summary of which is that the ODR-uniquing of types is happening at 
such a low of a level that it causes surprises and can't be easily fixed. 
Here's a more well designed reproducer:

inline int foo() {
  class bar {
  private:
int a = 0;
  public:
int get_a() { return a; }
  };

  static bar baz;
  return baz.get_a();
}

int a() {
  return foo();
}

Compile and link this similar to above:
clang a.cpp  -o b.ll -emit-llvm -S -g -c -O2
clang b.cpp  -o b.ll -emit-llvm -S -g -c -O2
llvm-link a.ll b.ll -o c.ll -S
llc c.ll -o out.o -filetype=obj


Where b.cpp is a copy of the file above with the function renamed from 'a' to 
'b' to ensure there aren't multiple conflicting definitions. In this code, we 
inline the body of "foo" into the 'a' and 'b' functions, and furthermore we 
inline the get_a method of foo::bar too. In each of the compilation units, this 
leads to a chain of lexical scopes for the most deeply inlined instruction of:
 * get_a method,
 * foo::bar class
 * foo function
 * 'a' or 'b' function.

The trouble comes when the two modules are linked together: the two collections 
of DILocations / DILexicalScopes / DISubprograms describing source-locations in 
each module are distinct and kept separate through linking. However the 
DICompositeType for foo::bar is unique'd based on its name, and its "scope" 
field will point into one of the metadata collections. Thus, where we used to 
have two distinct chains of lexical scopes we've now got a tree of them, 
joining at the unique'd DICompositeType, and llc is not prepared for this.

I don't know that this is a bug, more of a design mismatch: most of the rest of 
LLVM is probably OK with having the lexical-scope chain actually being a tree, 
given that it only ever looks up it. However LexicalScopes does a top down 
exploration of a function looking for lexical scopes, and is then surprised 
when it finds different scopes looking from the bottom up. We could adjust it 
to search upwards for more lexical scopes (it already does that for 
block-scopes), but then I imagine we would produce very confusing DWARF that 
contained two Subprogram scopes for the same function.

There's also no easy way of working around this in metadata: we can't describe 
any other metadata relationship because it's done at such a low level, and we 
can't selectively not-ODR-unique DICompositeTypes that are inside functions 
because the lexical scope metadata might not have been loaded yet, so can't be 
examined.

An immediate fix would be to not set the "identifier" field for the 
DICompositeType when it's created if it's inside a function scope to avoid 
ODRUniqing. I've only got a light understanding of what the identifier field is 
for, so there might be unexpected consequences, plus there'll be a 
metadata/DWARF size cost to that.

https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PS5][Driver] Restore whole-archive state when `-fjmc` (PR #115181)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse approved this pull request.

LGTM, although maybe CHECK_JMC instead of CHECK_LIB as it seems very JMC 
specific? No strong opinion.

https://github.com/llvm/llvm-project/pull/115181
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

https://github.com/jmorse commented:

Some minor test comments, otherwise looking good,

https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -0,0 +1,30 @@
+/// Check that we generate fake uses only when -fextend-lifetimes is set and we
+/// are not setting optnone, or when we have optimizations set to -Og and we 
have
+/// not passed -fno-extend-lifetimes.
+// RUN: %clang_cc1 -emit-llvm -disable-llvm-passes -O0 -fextend-lifetimes %s 
-o - | FileCheck %s

jmorse wrote:

Intention of this RUN line is that no fake uses are generated, but there are no 
test-lines for ensuring that -> add an implicit-fake-not? And the other 
check-only FileCheck commands.

https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -441,6 +441,10 @@ Modified Compiler Flags
   ``memset`` and similar functions for which it is a documented undefined
   behavior. It is implied by ``-Wnontrivial-memaccess``
 
+- The ``-Og`` optimization flag now sets ``-fextend-lifetimes``, a new compiler
+  flag, resulting in slightly reduced optimization compared to ``-O1`` in

jmorse wrote:

Can we just say "trading optimization for improved..." to indicate that this is 
a conscious decision the developer might make?

https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

https://github.com/jmorse edited 
https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse 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 set any explicit -fextend-lifetimes
+  // value, then default to -fextend-lifetimes=all.

jmorse wrote:

This is going to create confusion by speculating the existence of an 
`={all,params,this}`  fextend-lifetimes when it doesn't exist yet, and might 
not.

https://github.com/llvm/llvm-project/pull/118026
___
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)

[Jeremy Morse via cfe-commits]

jmorse wrote:

The additions here look fine; however I think there's generally precedent that 
anything we add needs to have /some/ kind of test, or be covered by something 
already existing, otherwise we're vulnerable to:
 * Patch lands,
 * Someone refactors clang switch handling,
 * Other patches land but the flag doesn't do anything / is rejected,
 * Confusion reigns

As far as I understand it, these are driver options that will be passed through 
to cc1? In that case we can at least test the passthrough, i.e. that 
`-fextend-lifetimes` appears in the output of `-###`.

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] [Clang] Add fake use emission to Clang with -fextend-lifetimes (PR #110102)

[Jeremy Morse via cfe-commits]

https://github.com/jmorse commented:

Tests are looking better (and github has helpfully thrown away most of my 
comments). I'll look at the code too now.

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

https://github.com/jmorse edited 
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 %s -O0 -disable-O0-optnone -emit-llvm -fextend-lifetimes 
-fsanitize=null -fsanitize-trap=null -o - | FileCheck 
--check-prefixes=CHECK,NULL --implicit-check-not=ubsantrap %s
+// RUN: %clang_cc1 %s -O0 -disable-O0-optnone -emit-llvm -fextend-lifetimes -o 
- | FileCheck %s
+
+// With -fextend-lifetimes, the compiler previously generated a fake.use of any
+// reference variable at the end of the scope in which its alloca exists. This
+// caused two issues, where we would get fake uses for uninitialized variables
+// if that variable was declared after an early-return, and UBSan's null checks
+// would complain about this.
+// This test verifies that UBSan does not produce null-checks for arguments to
+// llvm.fake.use, and that fake uses are not emitted for a variable on paths
+// it has not been declared.

jmorse wrote:

Thanks for regenerating this with no optimisations happening; am I right in 
thinking that `-fsanitize=null` doesn't just turn off the sanitizer, it turns 
on ubsan for null values or something? I see there are calls to ubsantrap being 
generated, and want to settle my understanding of this.

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -0,0 +1,27 @@
+// RUN: %clang %s -S -emit-llvm -fextend-lifetimes -O2 -o - 
-fno-discard-value-names | FileCheck %s
+//
+// Check we can correctly produce fake uses for function-level variables even
+// when we have a return in a nested conditional and there is no code at the 
end
+// of the function.

jmorse wrote:

I see this is now O0 and disable-O0-optnone, would this not be even better 
spelt as just `-disable-llvm-passes`? IMHO that's a much more substantially 
direct way of signalling "none of LLVM will run".

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 %s -O0 -emit-llvm -fextend-this-ptr -o -  | FileCheck %s \
+// RUN:  --implicit-check-not="call void (...) @llvm.fake.use"
+// RUN: %clang_cc1 %s -O0 -emit-llvm -fextend-lifetimes -o - | FileCheck %s \
+// RUN:  --implicit-check-not="call void (...) @llvm.fake.use"
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-this-ptr -o -  | FileCheck 
-check-prefix=OPT %s
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-lifetimes -o - | FileCheck 
-check-prefix=OPT %s
+// RUN: %clang_cc1 %s -Os -emit-llvm -fextend-this-ptr -o -  | FileCheck 
-check-prefix=OPT %s
+// RUN: %clang_cc1 %s -Os -emit-llvm -fextend-lifetimes -o - | FileCheck 
-check-prefix=OPT %s
+// RUN: %clang_cc1 %s -Oz -emit-llvm -fextend-this-ptr -o -  | FileCheck 
-check-prefix=OPT %s
+// RUN: %clang_cc1 %s -Oz -emit-llvm -fextend-lifetimes -o - | FileCheck 
-check-prefix=OPT %s
+// Check that we do not generate a fake_use call when we are not optimizing. 

jmorse wrote:

I reckon these can all be given `--disable-llvm-passes` too, as what we're 
checking is the effect of the optimisation flag on clang, not on the actual 
pipeline.

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

https://github.com/jmorse edited 
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -1412,6 +1425,39 @@ void 
CodeGenFunction::EmitAndRegisterVariableArrayDimensions(
   }
 }
 
+/// Return the maximum size of an aggregate for which we generate a fake use
+/// intrinsic when -fextend-lifetimes is in effect.
+static uint64_t maxFakeUseAggregateSize(const ASTContext &C) {
+  return 4 * C.getTypeSize(C.UnsignedIntTy);
+}
+
+// Helper function to determine whether a variable's or parameter's lifetime
+// should be extended.
+static bool extendLifetime(const ASTContext &Context, const Decl *FuncDecl,

jmorse wrote:

IMO: this function should be named `shouldExtendLifetime`

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

https://github.com/jmorse commented:

Looking good, some comments and questions.

Having to fiddle with `findDominatingStoreToReturnValue` to make it skip 
fake-uses is slightly worrying, but it also says it's a heuristic and thus 
probably not fundamental for correctness?

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -1664,6 +1710,17 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl &D) {
  
emission.getOriginalAllocatedAddress(),
  emission.getSizeForLifetimeMarkers());
 
+  // Analogous to lifetime markers, we use a 'cleanup' to emit fake.use
+  // calls for local variables. We are exempting volatile variables and
+  // non-scalars larger than 4 times the size of an unsigned int (32 bytes).
+  // Larger non-scalars are often allocated in memory and may create 
unnecessary
+  // overhead.
+  if (CGM.getCodeGenOpts().ExtendLifetimes) {
+if (extendLifetime(getContext(), CurCodeDecl, D, CXXABIThisDecl))
+  EHStack.pushCleanup(NormalFakeUse,
+   emission.getAllocatedAddress());

jmorse wrote:

I see the nearby EHStack cleanup code uses getOriginalAllocatedAddress -- 
should we be using that instead? Related comments talk about there being a 
difference the address and the object; dunno what to make of that, but it's 
worth checking.

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -1664,6 +1710,17 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl &D) {
  
emission.getOriginalAllocatedAddress(),
  emission.getSizeForLifetimeMarkers());
 
+  // Analogous to lifetime markers, we use a 'cleanup' to emit fake.use
+  // calls for local variables. We are exempting volatile variables and
+  // non-scalars larger than 4 times the size of an unsigned int (32 bytes).

jmorse wrote:

16 bytes presumably, or 32 bits for unsigned int? Best to avoid being too 
specific IMO as it's machine dependent. (Perhaps all the world's a VAX, but we 
can avoid saying it in comments).

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse 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 might not apply it anyway due to minsize or similar attributes.
+  if (!CGM.getCodeGenOpts().DisableO0ImplyOptNone &&
+  CGM.getCodeGenOpts().OptimizationLevel == 0)
+return;

jmorse wrote:

Hm. It feels a bit wrong to bake this kind of high level decision this deep 
into the code. Would it be better to instead have the clang driver decide 
whether to enable fextend-lifetimes depending on the optimisation mode, then 
pass the flag to cc1, and not have this kind of check?

This would reduce our testing matrix in the future to separate "cc1 does 
fextend lifetimes correctly" from  "when should fextend-lifetimes be done".

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -112,11 +112,11 @@ void EHScopeStack::deallocate(size_t Size) {
   StartOfData += llvm::alignTo(Size, ScopeStackAlignment);
 }
 
-bool EHScopeStack::containsOnlyLifetimeMarkers(
+bool EHScopeStack::containsOnlyNoopCleanups(
 EHScopeStack::stable_iterator Old) const {
   for (EHScopeStack::iterator it = begin(); stabilize(it) != Old; it++) {
 EHCleanupScope *cleanup = dyn_cast(&*it);
-if (!cleanup || !cleanup->isLifetimeMarker())
+if (!cleanup || !(cleanup->isLifetimeMarker() || cleanup->isFakeUse()))

jmorse wrote:

I feel like the number of inversions here makes it harder to read; how about 
the suggestion,
```suggestion
if (!cleanup)
  return false
if (!cleanup->isLifetimeMarker() && !cleanup->isFakeUse()))
  return false;
```
I.e. it's slightly clearer that it's a dont-dereference-null check and a 
is-it-not-a-noop check.

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

https://github.com/jmorse commented:

Behold, I've added a bunch of pedantic comments about the tests.

I think a significant matter is that they all run an LLVM optimisation 
pipeline, which I believe means they cover too much of the project to be 
"clang" tests, they're more end-to-end or cross project tests. Potentially we 
can move them there; it's more preferable to test for the exact output of clang 
without the optimisation passes instead though.

(If there's optimisation behaviour that does need testing, it should be part of 
the relevant LLVM pass).

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 %s -triple=%itanium_abi_triple -O1 -emit-llvm 
-fextend-lifetimes -o - | FileCheck %s
+// Make sure we don't crash compiling a lambda that is not nested in a 
function.
+// We also check that fake uses are properly issued in lambdas.
+
+int glob;
+
+extern int foo();
+
+struct S {
+  static const int a;
+};
+
+const int S::a = [](int b) __attribute__((noinline)) {
+  return b * foo();
+}
+(glob);
+
+int func(int param) {
+  return ([=](int lambdaparm) __attribute__((noinline))->int {
+int lambdalocal = lambdaparm * 2;
+return lambdalocal;
+  }(glob));
+}
+
+// We are looking for the first lambda's call operator, which should contain
+// 2 fake uses, one for 'b' and one for its 'this' pointer (in that order).
+// The mangled function name contains a $_0, followed by 'cl'.
+// This lambda is an orphaned lambda, i.e. one without lexical parent.
+//
+// CHECK: define internal {{.+\"_Z.+\$_0.*cl.*\"}}

jmorse wrote:

CHECK-LABEL, and for the other define below?

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Jeremy Morse via cfe-commits]

@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 %s -O2 -emit-llvm -fextend-lifetimes -o - | FileCheck %s
+// Make sure we don't generate fake.use for non-scalar variables.
+// Make sure we don't generate fake.use for volatile variables
+// and parameters even when they are scalar.
+
+struct A {
+  unsigned long t;
+  char c[1024];
+  unsigned char r[32];
+};
+
+
+int foo(volatile int param)
+{
+  struct A s;
+  volatile int vloc;
+  struct A v[128];
+  char c[33];
+  return 0;
+}
+
+// CHECK-NOT:  fake.use

jmorse wrote:

This wants a positive check condition, so that we're actually testing clang 
produced an LLVM-IR output. (Better to have fake.use in an implicit-check-not?)

https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits