r314187 - CodeGenModule: Adapt to LLVM TargetLibraryInfo changes

2017-09-25 Thread Matthias Braun via cfe-commits
Author: matze
Date: Mon Sep 25 19:37:23 2017
New Revision: 314187

URL: http://llvm.org/viewvc/llvm-project?rev=314187&view=rev
Log:
CodeGenModule: Adapt to LLVM TargetLibraryInfo changes

Adapt to LLVM TargetLibraryInfo changes in r314185.

See also https://reviews.llvm.org/D38106 and https://reviews.llvm.org/D37891

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=314187&r1=314186&r2=314187&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Sep 25 19:37:23 2017
@@ -476,17 +476,11 @@ void CodeGenModule::Release() {
 getModule().addModuleFlag(llvm::Module::Warning, "Debug Info Version",
   llvm::DEBUG_METADATA_VERSION);
 
-  // Width of wchar_t in bytes
-  uint64_t WCharWidth =
-  Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
-  assert((LangOpts.ShortWChar ||
-  llvm::TargetLibraryInfoImpl::getTargetWCharSize(Target.getTriple()) 
==
-  Target.getWCharWidth() / 8) &&
- "LLVM wchar_t size out of sync");
-
   // We need to record the widths of enums and wchar_t, so that we can generate
   // the correct build attributes in the ARM backend. wchar_size is also used 
by
   // TargetLibraryInfo.
+  uint64_t WCharWidth =
+  Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
   getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
 
   llvm::Triple::ArchType Arch = Context.getTargetInfo().getTriple().getArch();


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


[PATCH] D24820: Add -stats-file option

2016-09-21 Thread Matthias Braun via cfe-commits
MatzeB created this revision.
MatzeB added reviewers: bruno, rsmith, aprantl.
MatzeB added a subscriber: cfe-commits.
MatzeB set the repository for this revision to rL LLVM.
Herald added a subscriber: mcrosier.

This option behaves in a similar spirit as -save-temps and writes out
llvm statistics in json format.

Repository:
  rL LLVM

https://reviews.llvm.org/D24820

Files:
  include/clang/Basic/DiagnosticFrontendKinds.td
  include/clang/Driver/CC1Options.td
  include/clang/Driver/Options.td
  include/clang/Frontend/FrontendOptions.h
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInstance.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  test/Driver/save-stats.c
  test/Frontend/stats-file.c
  test/Misc/warning-flags.c

Index: test/Misc/warning-flags.c
===
--- test/Misc/warning-flags.c
+++ test/Misc/warning-flags.c
@@ -18,7 +18,7 @@
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (84):
+CHECK: Warnings without flags (85):
 CHECK-NEXT:   ext_excess_initializers
 CHECK-NEXT:   ext_excess_initializers_in_char_array_initializer
 CHECK-NEXT:   ext_expected_semi_decl_list
@@ -66,6 +66,7 @@
 CHECK-NEXT:   warn_fe_cc_log_diagnostics_failure
 CHECK-NEXT:   warn_fe_cc_print_header_failure
 CHECK-NEXT:   warn_fe_macro_contains_embedded_newline
+CHECK-NEXT:   warn_fe_unable_to_open_stats_file
 CHECK-NEXT:   warn_file_asm_volatile
 CHECK-NEXT:   warn_ignoring_ftabstop_value
 CHECK-NEXT:   warn_implements_nscopying
Index: test/Frontend/stats-file.c
===
--- /dev/null
+++ test/Frontend/stats-file.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm -o /dev/null -stats-file=%t %s
+// RUN: FileCheck -input-file=%t %s
+// CHECK: {
+//  ... here come some json values ...
+// CHECK: }
+
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%S/doesnotexist/bla %s 2>&1 | FileCheck -check-prefix=OUTPUTFAIL %s
+// OUTPUTFAIL: warning: unable to open statistic output file '{{.*}}{{[/\\]}}doesnotexist{{[/\\]}}bla': '{{[Nn]}}o such file or directory'
Index: test/Driver/save-stats.c
===
--- /dev/null
+++ test/Driver/save-stats.c
@@ -0,0 +1,17 @@
+// RUN: %clang -target x86_64-apple-darwin -save-stats %s -### 2>&1 | FileCheck %s
+// RUN: %clang -target x86_64-apple-darwin -save-stats=cwd %s -### 2>&1 | FileCheck %s
+// CHECK: "-stats-file=save-stats.stats"
+// CHECK: "{{.*}}save-stats.c"
+
+// RUN: %clang -target x86_64-apple-darwin -S %s -### 2>&1 | FileCheck %s -check-prefix=NO-STATS
+// NO-STATS-NO: -stats-file
+// NO-STATS: "{{.*}}save-stats.c"
+// NO-STATS-NO: -stats-file
+
+// RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c -o obj/dir/save-stats.o %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ
+// CHECK-OBJ: "-stats-file=obj/dir{{/|}}save-stats.stats"
+// CHECK-OBJ: "-o" "obj/dir{{/|}}save-stats.o"
+
+// RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ-NOO
+// CHECK-OBJ-NOO: "-stats-file=save-stats.stats"
+// CHECK-OBJ-NOO: "-o" "save-stats.o"
Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -194,8 +194,10 @@
   }
 
   ~AnalysisConsumer() override {
-if (Opts->PrintStats)
+if (Opts->PrintStats) {
   delete TUTotalTimer;
+  llvm::PrintStatistics();
+}
   }
 
   void DigestAnalyzerOptions() {
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1252,6 +1252,7 @@
   Opts.AuxTriple =
   llvm::Triple::normalize(Args.getLastArgValue(OPT_aux_triple));
   Opts.FindPchSource = Args.getLastArgValue(OPT_find_pch_source_EQ);
+  Opts.StatsFile = Args.getLastArgValue(OPT_stats_file);
 
   if (const Arg *A = Args.getLastArg(OPT_arcmt_check,
  OPT_arcmt_modify,
Index: lib/Frontend/CompilerInstance.cpp
===
--- lib/Frontend/CompilerInstance.cpp
+++ lib/Frontend/CompilerInstance.cpp
@@ -858,7 +858,7 @@
   if (getFrontendOpts().ShowTimers)
 createFrontendTimer();
 
-  if (getFrontendOpts().ShowStats)
+  if (getFrontendOpts().ShowStats || !getFrontendOpts().StatsFile.empty())
 llvm::EnableStatistics();
 
   for (const FrontendInputFile &FIF : getFrontendOpts().Inputs) {
@@ -892,9 +892,24 @@
   OS << " generated.\n";
   }
 
-  if (getFrontendOpts().ShowStats && hasFileManager()) {
-getFileManager().PrintStats();
-OS << "\n";
+  if (getFrontendOpts().ShowStats) {
+if (hasFileManager()) {
+  getFileManager().Pr

Re: [PATCH] D24820: Add -stats-file option

2016-09-23 Thread Matthias Braun via cfe-commits
MatzeB added inline comments.


Comment at: lib/Driver/Tools.cpp:6102
@@ +6101,3 @@
+StatsFile.assign(Output.getFilename());
+llvm::sys::path::remove_filename(StatsFile);
+  }

bruno wrote:
> Why removing StatsFile here? IIUC, at this point StatsFile is still the same 
> as the output (if it's a file).
a) It behaves like -save-temps=obj (`clang -save-temps=obj foo.c -o bar` will 
give you foo.i, foo.o, ...;
b) This makes sense when you have multiple (`clang -save-stats=obj foo.c bar.c 
-o baz`) inputs for which you need multiple .stats filenames but you only have 
1 output name 
c) It magically works for `-o -` as well



Repository:
  rL LLVM

https://reviews.llvm.org/D24820



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


Re: [PATCH] D24820: Add -stats-file option

2016-09-23 Thread Matthias Braun via cfe-commits
MatzeB updated this revision to Diff 72376.
MatzeB marked an inline comment as done.
MatzeB added a comment.

Thanks for the reviews.

Addressed comments.


Repository:
  rL LLVM

https://reviews.llvm.org/D24820

Files:
  docs/CommandGuide/clang.rst
  include/clang/Basic/DiagnosticFrontendKinds.td
  include/clang/Driver/CC1Options.td
  include/clang/Driver/Options.td
  include/clang/Frontend/FrontendOptions.h
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInstance.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  test/Driver/save-stats.c
  test/Frontend/stats-file.c
  test/Misc/warning-flags.c

Index: test/Misc/warning-flags.c
===
--- test/Misc/warning-flags.c
+++ test/Misc/warning-flags.c
@@ -18,7 +18,7 @@
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (84):
+CHECK: Warnings without flags (85):
 CHECK-NEXT:   ext_excess_initializers
 CHECK-NEXT:   ext_excess_initializers_in_char_array_initializer
 CHECK-NEXT:   ext_expected_semi_decl_list
@@ -66,6 +66,7 @@
 CHECK-NEXT:   warn_fe_cc_log_diagnostics_failure
 CHECK-NEXT:   warn_fe_cc_print_header_failure
 CHECK-NEXT:   warn_fe_macro_contains_embedded_newline
+CHECK-NEXT:   warn_fe_unable_to_open_stats_file
 CHECK-NEXT:   warn_file_asm_volatile
 CHECK-NEXT:   warn_ignoring_ftabstop_value
 CHECK-NEXT:   warn_implements_nscopying
Index: test/Frontend/stats-file.c
===
--- /dev/null
+++ test/Frontend/stats-file.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm -o /dev/null -stats-file=%t %s
+// RUN: FileCheck -input-file=%t %s
+// CHECK: {
+//  ... here come some json values ...
+// CHECK: }
+
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%S/doesnotexist/bla %s 2>&1 | FileCheck -check-prefix=OUTPUTFAIL %s
+// OUTPUTFAIL: warning: unable to open statistic output file '{{.*}}{{[/\\]}}doesnotexist{{[/\\]}}bla': '{{[Nn]}}o such file or directory'
Index: test/Driver/save-stats.c
===
--- /dev/null
+++ test/Driver/save-stats.c
@@ -0,0 +1,20 @@
+// RUN: %clang -target x86_64-apple-darwin -save-stats %s -### 2>&1 | FileCheck %s
+// RUN: %clang -target x86_64-apple-darwin -save-stats=cwd %s -### 2>&1 | FileCheck %s
+// CHECK: "-stats-file=save-stats.stats"
+// CHECK: "{{.*}}save-stats.c"
+
+// RUN: %clang -target x86_64-apple-darwin -S %s -### 2>&1 | FileCheck %s -check-prefix=NO-STATS
+// NO-STATS-NO: -stats-file
+// NO-STATS: "{{.*}}save-stats.c"
+// NO-STATS-NO: -stats-file
+
+// RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c -o obj/dir/save-stats.o %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ
+// CHECK-OBJ: "-stats-file=obj/dir{{.}}save-stats.stats"
+// CHECK-OBJ: "-o" "obj/dir{{.}}save-stats.o"
+
+// RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ-NOO
+// CHECK-OBJ-NOO: "-stats-file=save-stats.stats"
+// CHECK-OBJ-NOO: "-o" "save-stats.o"
+
+// RUN: %clang -target x86_64-apple-darwin -save-stats=bla -c %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-INVALID
+// CHECK-INVALID: invalid value 'bla' in '-save-stats=bla'
Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -194,8 +194,10 @@
   }
 
   ~AnalysisConsumer() override {
-if (Opts->PrintStats)
+if (Opts->PrintStats) {
   delete TUTotalTimer;
+  llvm::PrintStatistics();
+}
   }
 
   void DigestAnalyzerOptions() {
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1252,6 +1252,7 @@
   Opts.AuxTriple =
   llvm::Triple::normalize(Args.getLastArgValue(OPT_aux_triple));
   Opts.FindPchSource = Args.getLastArgValue(OPT_find_pch_source_EQ);
+  Opts.StatsFile = Args.getLastArgValue(OPT_stats_file);
 
   if (const Arg *A = Args.getLastArg(OPT_arcmt_check,
  OPT_arcmt_modify,
Index: lib/Frontend/CompilerInstance.cpp
===
--- lib/Frontend/CompilerInstance.cpp
+++ lib/Frontend/CompilerInstance.cpp
@@ -858,7 +858,7 @@
   if (getFrontendOpts().ShowTimers)
 createFrontendTimer();
 
-  if (getFrontendOpts().ShowStats)
+  if (getFrontendOpts().ShowStats || !getFrontendOpts().StatsFile.empty())
 llvm::EnableStatistics();
 
   for (const FrontendInputFile &FIF : getFrontendOpts().Inputs) {
@@ -892,9 +892,24 @@
   OS << " generated.\n";
   }
 
-  if (getFrontendOpts().ShowStats && hasFileManager()) {
-getFileManager().PrintStats();
-OS << "\n";
+  if (getFrontendOpts().ShowStats) {
+if (has

Re: [PATCH] D24820: Add -stats-stats option

2016-09-23 Thread Matthias Braun via cfe-commits
MatzeB added inline comments.


Comment at: test/Driver/save-stats.c:1
@@ +1,2 @@
+// RUN: %clang -target x86_64-apple-darwin -save-stats %s -### 2>&1 | 
FileCheck %s
+// RUN: %clang -target x86_64-apple-darwin -save-stats=cwd %s -### 2>&1 | 
FileCheck %s

bruno wrote:
> Is -save-stats == -save-stats=cwd? It doesn't seem so by looking at 
> lib/Driver/Tools.cpp. Need test for the diag::err_drv_invalid_value as well.
Yes, that aspect is handled by the options parser, look at the changes in 
Options.td


Repository:
  rL LLVM

https://reviews.llvm.org/D24820



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


r282426 - CC1: Add -save-stats option

2016-09-26 Thread Matthias Braun via cfe-commits
Author: matze
Date: Mon Sep 26 13:53:34 2016
New Revision: 282426

URL: http://llvm.org/viewvc/llvm-project?rev=282426&view=rev
Log:
CC1: Add -save-stats option

This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.

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

Added:
cfe/trunk/test/Driver/save-stats.c
cfe/trunk/test/Frontend/stats-file.c
Modified:
cfe/trunk/docs/CommandGuide/clang.rst
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/FrontendOptions.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
cfe/trunk/test/Misc/warning-flags.c

Modified: cfe/trunk/docs/CommandGuide/clang.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CommandGuide/clang.rst?rev=282426&r1=282425&r2=282426&view=diff
==
--- cfe/trunk/docs/CommandGuide/clang.rst (original)
+++ cfe/trunk/docs/CommandGuide/clang.rst Mon Sep 26 13:53:34 2016
@@ -408,6 +408,12 @@ Driver Options
 
   Save intermediate compilation results.
 
+.. option:: -save-stats, -save-stats=cwd, -save-stats=obj
+
+  Save internal code generation (LLVM) statistics to a file in the current
+  directory (:option:`-save-stats`/:option:`-save-stats=cwd`) or the directory
+  of the output file (:option:`-save-state=obj`).
+
 .. option:: -integrated-as, -no-integrated-as
 
   Used to enable and disable, respectively, the use of the integrated

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=282426&r1=282425&r2=282426&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Sep 26 
13:53:34 2016
@@ -107,6 +107,8 @@ def warn_fe_cc_print_header_failure : Wa
 "unable to open CC_PRINT_HEADERS file: %0 (using stderr)">;
 def warn_fe_cc_log_diagnostics_failure : Warning<
 "unable to open CC_LOG_DIAGNOSTICS file: %0 (using stderr)">;
+def warn_fe_unable_to_open_stats_file : Warning<
+"unable to open statistics output file '%0': '%1'">;
 def err_fe_no_pch_in_dir : Error<
 "no suitable precompiled header file found in directory '%0'">;
 def err_fe_action_not_available : Error<

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=282426&r1=282425&r2=282426&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Sep 26 13:53:34 2016
@@ -509,6 +509,8 @@ def arcmt_migrate : Flag<["-"], "arcmt-m
 
 def print_stats : Flag<["-"], "print-stats">,
   HelpText<"Print performance metrics and statistics">;
+def stats_file : Joined<["-"], "stats-file=">,
+  HelpText<"Filename to write statistics to">;
 def fdump_record_layouts : Flag<["-"], "fdump-record-layouts">,
   HelpText<"Dump record layout information">;
 def fdump_record_layouts_simple : Flag<["-"], "fdump-record-layouts-simple">,

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=282426&r1=282425&r2=282426&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Mon Sep 26 13:53:34 2016
@@ -1876,6 +1876,11 @@ def save_temps_EQ : Joined<["-", "--"],
 def save_temps : Flag<["-", "--"], "save-temps">, Flags<[DriverOption]>,
   Alias, AliasArgs<["cwd"]>,
   HelpText<"Save intermediate compilation results">;
+def save_stats_EQ : Joined<["-", "--"], "save-stats=">, Flags<[DriverOption]>,
+  HelpText<"Save llvm statistics.">;
+def save_stats : Flag<["-", "--"], "save-stats">, Flags<[DriverOption]>,
+  Alias, AliasArgs<["cwd"]>,
+  HelpText<"Save llvm statistics.">;
 def via_file_asm : Flag<["-", "--"], "via-file-asm">, InternalDebugOpt,
   HelpText<"Write assembly to file for input to assemble jobs">;
 def sectalign : MultiArg<["-"], "sectalign", 3>;

Modified: cfe/trunk/include/clang/Frontend/FrontendOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendOptions.h?rev=282426&r1=282425&r2=282426&view=diff
==
--- cfe/trunk/include/clang/Frontend/FrontendOptions.h (original)
+++ cfe/trunk/include/clang/Frontend/Frontend

Re: [PATCH] D24820: Add -stats-stats option

2016-09-26 Thread Matthias Braun via cfe-commits
MatzeB added inline comments.


Comment at: test/Driver/save-stats.c:12
@@ +11,3 @@
+// RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c -o 
obj/dir/save-stats.o %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ
+// CHECK-OBJ: "-stats-file=obj/dir{{/|}}save-stats.stats"
+// CHECK-OBJ: "-o" "obj/dir{{/|}}save-stats.o"

bruno wrote:
> aprantl wrote:
> > This is up to taste, but just accepting {{.}} as the path separator would 
> > be sufficient IMO and might be more readable.
> +1 to Adrian's suggestion
For the record: Switching to {{.}} in the final commit broke the windows bots, 
because they display an escaped slash here (= two backslash characters)...


Repository:
  rL LLVM

https://reviews.llvm.org/D24820



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


r282438 - Fix test on windows

2016-09-26 Thread Matthias Braun via cfe-commits
Author: matze
Date: Mon Sep 26 15:48:34 2016
New Revision: 282438

URL: http://llvm.org/viewvc/llvm-project?rev=282438&view=rev
Log:
Fix test on windows

Modified:
cfe/trunk/test/Driver/save-stats.c

Modified: cfe/trunk/test/Driver/save-stats.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/save-stats.c?rev=282438&r1=282437&r2=282438&view=diff
==
--- cfe/trunk/test/Driver/save-stats.c (original)
+++ cfe/trunk/test/Driver/save-stats.c Mon Sep 26 15:48:34 2016
@@ -9,8 +9,8 @@
 // NO-STATS-NO: -stats-file
 
 // RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c -o 
obj/dir/save-stats.o %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ
-// CHECK-OBJ: "-stats-file=obj/dir{{.}}save-stats.stats"
-// CHECK-OBJ: "-o" "obj/dir{{.}}save-stats.o"
+// CHECK-OBJ: "-stats-file=obj/dir{{/|}}save-stats.stats"
+// CHECK-OBJ: "-o" "obj/dir{{/|}}save-stats.o"
 
 // RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c %s -### 2>&1 | 
FileCheck %s -check-prefix=CHECK-OBJ-NOO
 // CHECK-OBJ-NOO: "-stats-file=save-stats.stats"


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


r282533 - Adapt to LLVM EnableStatistics() change.

2016-09-27 Thread Matthias Braun via cfe-commits
Author: matze
Date: Tue Sep 27 14:38:59 2016
New Revision: 282533

URL: http://llvm.org/viewvc/llvm-project?rev=282533&view=rev
Log:
Adapt to LLVM EnableStatistics() change.

Modified:
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=282533&r1=282532&r2=282533&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Tue Sep 27 14:38:59 2016
@@ -859,7 +859,7 @@ bool CompilerInstance::ExecuteAction(Fro
 createFrontendTimer();
 
   if (getFrontendOpts().ShowStats || !getFrontendOpts().StatsFile.empty())
-llvm::EnableStatistics();
+llvm::EnableStatistics(false);
 
   for (const FrontendInputFile &FIF : getFrontendOpts().Inputs) {
 // Reset the ID tables if we are reusing the SourceManager and parsing

Modified: cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp?rev=282533&r1=282532&r2=282533&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp Tue Sep 27 
14:38:59 2016
@@ -188,7 +188,7 @@ public:
 Injector(injector) {
 DigestAnalyzerOptions();
 if (Opts->PrintStats) {
-  llvm::EnableStatistics();
+  llvm::EnableStatistics(false);
   TUTotalTimer = new llvm::Timer("Analyzer Total Time");
 }
   }


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


r282557 - Put new warning in a diagnostic group.

2016-09-27 Thread Matthias Braun via cfe-commits
Author: matze
Date: Tue Sep 27 18:44:38 2016
New Revision: 282557

URL: http://llvm.org/viewvc/llvm-project?rev=282557&view=rev
Log:
Put new warning in a diagnostic group.

The warning I added in r282426 should be a diagnostic group.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/test/Misc/warning-flags.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=282557&r1=282556&r2=282557&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Sep 27 
18:44:38 2016
@@ -108,7 +108,8 @@ def warn_fe_cc_print_header_failure : Wa
 def warn_fe_cc_log_diagnostics_failure : Warning<
 "unable to open CC_LOG_DIAGNOSTICS file: %0 (using stderr)">;
 def warn_fe_unable_to_open_stats_file : Warning<
-"unable to open statistics output file '%0': '%1'">;
+"unable to open statistics output file '%0': '%1'">,
+InGroup>;
 def err_fe_no_pch_in_dir : Error<
 "no suitable precompiled header file found in directory '%0'">;
 def err_fe_action_not_available : Error<

Modified: cfe/trunk/test/Misc/warning-flags.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/warning-flags.c?rev=282557&r1=282556&r2=282557&view=diff
==
--- cfe/trunk/test/Misc/warning-flags.c (original)
+++ cfe/trunk/test/Misc/warning-flags.c Tue Sep 27 18:44:38 2016
@@ -18,7 +18,7 @@ This test serves two purposes:
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (85):
+CHECK: Warnings without flags (84):
 CHECK-NEXT:   ext_excess_initializers
 CHECK-NEXT:   ext_excess_initializers_in_char_array_initializer
 CHECK-NEXT:   ext_expected_semi_decl_list
@@ -66,7 +66,6 @@ CHECK-NEXT:   warn_extraneous_char_const
 CHECK-NEXT:   warn_fe_cc_log_diagnostics_failure
 CHECK-NEXT:   warn_fe_cc_print_header_failure
 CHECK-NEXT:   warn_fe_macro_contains_embedded_newline
-CHECK-NEXT:   warn_fe_unable_to_open_stats_file
 CHECK-NEXT:   warn_file_asm_volatile
 CHECK-NEXT:   warn_ignoring_ftabstop_value
 CHECK-NEXT:   warn_implements_nscopying


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


Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

2016-09-28 Thread Matthias Braun via cfe-commits
If we do this we should at least be targetted and restrict it to the tests that 
need the flag. For example you could put:
   list(APPEND CFLAGS -ffp-contract=off)to 
MultiSource/Applications/oggenc/CMakeLists.txt
and
  CFLAGS += -ffp-contract=off   into MultiSource/Applications/oggenc/Makefile

that at least forces us to think about why a specific benchmark fails and maybe 
we can find a way to rather use fpcmp/set an absolution/relative tollerance for 
when comparing the results (though admittedly I don't see how we can do that in 
a case of oggenc where a .ogg file is produced).

- Matthias

> On Sep 23, 2016, at 2:53 PM, Hal Finkel via cfe-commits 
>  wrote:
> 
> We currently have logic in the test suite that sets -ffp-contract=off on 
> PowerPC (because the default for GCC and other compilers on PowerPC/Linux 
> systems is essentially -ffp-contract=fast). We might just want to do this now 
> for all platforms.
> 
> -Hal
> 
> - Original Message -
>> From: "Steve Canon" mailto:sca...@apple.com>>
>> To: reviews+d24481+public+c0b8d50a92298...@reviews.llvm.org 
>> 
>> Cc: "a skolnik" mailto:a.skol...@samsung.com>>, 
>> clatt...@apple.com , hfin...@anl.gov 
>> , "yaxun liu" > >,
>> cfe-commits@lists.llvm.org 
>> Sent: Friday, September 23, 2016 4:47:32 PM
>> Subject: Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default
>> 
>> Without digging into them yet, these are almost caused by
>> overly-sensitive tests that are erroneously expecting bit-exact
>> results.
>> 
>> - Steve
>> 
>> Sent from my iPhone
>> 
>>> On Sep 23, 2016, at 4:42 PM, Renato Golin 
>>> wrote:
>>> 
>>> rengolin added a subscriber: rengolin.
>>> rengolin added a comment.
>>> 
>>> Folks, this commit has broken both AArch64 test-suite buildbots:
>>> 
>>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3162
>>> 
>>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/10449
>>> 
>>> I have reverted in r282289, let me know if you need help testing on
>>> AArch64.
>>> 
>>> 
>>> Repository:
>>> rL LLVM
>>> 
>>> https://reviews.llvm.org/D24481
>>> 
>>> 
>>> 
>> 
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits 
> 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang-tools-extra] Remove unused LoopInfo from InlineSpiller and SpillPlacement (NFC) (PR #71874)

2023-11-16 Thread Matthias Braun via cfe-commits

https://github.com/MatzeB updated 
https://github.com/llvm/llvm-project/pull/71874

>From 3b502f8cc14456b325efc3017a4a114391284b37 Mon Sep 17 00:00:00 2001
From: Matthias Braun 
Date: Wed, 19 Oct 2022 10:58:40 -0700
Subject: [PATCH] Remove unused LoopInfo from InlineSpiller and SpillPlacement

---
 llvm/lib/CodeGen/CalcSpillWeights.cpp | 5 ++---
 llvm/lib/CodeGen/InlineSpiller.cpp| 9 ++---
 llvm/lib/CodeGen/SpillPlacement.cpp   | 4 
 llvm/lib/CodeGen/SpillPlacement.h | 2 --
 4 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/llvm/lib/CodeGen/CalcSpillWeights.cpp 
b/llvm/lib/CodeGen/CalcSpillWeights.cpp
index bf114921a7d220a..0d819e0298213b9 100644
--- a/llvm/lib/CodeGen/CalcSpillWeights.cpp
+++ b/llvm/lib/CodeGen/CalcSpillWeights.cpp
@@ -163,8 +163,6 @@ float VirtRegAuxInfo::weightCalcHelper(LiveInterval &LI, 
SlotIndex *Start,
   const TargetRegisterInfo &TRI = *MF.getSubtarget().getRegisterInfo();
   const TargetInstrInfo &TII = *MF.getSubtarget().getInstrInfo();
   MachineBasicBlock *MBB = nullptr;
-  MachineLoop *Loop = nullptr;
-  bool IsExiting = false;
   float TotalWeight = 0;
   unsigned NumInstr = 0; // Number of instructions using LI
   SmallPtrSet Visited;
@@ -260,9 +258,10 @@ float VirtRegAuxInfo::weightCalcHelper(LiveInterval &LI, 
SlotIndex *Start,
 float Weight = 1.0f;
 if (IsSpillable) {
   // Get loop info for mi.
+  bool IsExiting = false;
   if (MI->getParent() != MBB) {
 MBB = MI->getParent();
-Loop = Loops.getLoopFor(MBB);
+const MachineLoop *Loop = Loops.getLoopFor(MBB);
 IsExiting = Loop ? Loop->isLoopExiting(MBB) : false;
   }
 
diff --git a/llvm/lib/CodeGen/InlineSpiller.cpp 
b/llvm/lib/CodeGen/InlineSpiller.cpp
index 71d58b2e9e18d7d..e6d6fff96fbc519 100644
--- a/llvm/lib/CodeGen/InlineSpiller.cpp
+++ b/llvm/lib/CodeGen/InlineSpiller.cpp
@@ -33,7 +33,6 @@
 #include "llvm/CodeGen/MachineInstr.h"
 #include "llvm/CodeGen/MachineInstrBuilder.h"
 #include "llvm/CodeGen/MachineInstrBundle.h"
-#include "llvm/CodeGen/MachineLoopInfo.h"
 #include "llvm/CodeGen/MachineOperand.h"
 #include "llvm/CodeGen/MachineRegisterInfo.h"
 #include "llvm/CodeGen/SlotIndexes.h"
@@ -86,7 +85,6 @@ class HoistSpillHelper : private LiveRangeEdit::Delegate {
   LiveIntervals &LIS;
   LiveStacks &LSS;
   MachineDominatorTree &MDT;
-  MachineLoopInfo &Loops;
   VirtRegMap &VRM;
   MachineRegisterInfo &MRI;
   const TargetInstrInfo &TII;
@@ -138,8 +136,7 @@ class HoistSpillHelper : private LiveRangeEdit::Delegate {
VirtRegMap &vrm)
   : MF(mf), LIS(pass.getAnalysis()),
 LSS(pass.getAnalysis()),
-MDT(pass.getAnalysis()),
-Loops(pass.getAnalysis()), VRM(vrm),
+MDT(pass.getAnalysis()), VRM(vrm),
 MRI(mf.getRegInfo()), TII(*mf.getSubtarget().getInstrInfo()),
 TRI(*mf.getSubtarget().getRegisterInfo()),
 MBFI(pass.getAnalysis()),
@@ -157,7 +154,6 @@ class InlineSpiller : public Spiller {
   LiveIntervals &LIS;
   LiveStacks &LSS;
   MachineDominatorTree &MDT;
-  MachineLoopInfo &Loops;
   VirtRegMap &VRM;
   MachineRegisterInfo &MRI;
   const TargetInstrInfo &TII;
@@ -197,8 +193,7 @@ class InlineSpiller : public Spiller {
 VirtRegAuxInfo &VRAI)
   : MF(MF), LIS(Pass.getAnalysis()),
 LSS(Pass.getAnalysis()),
-MDT(Pass.getAnalysis()),
-Loops(Pass.getAnalysis()), VRM(VRM),
+MDT(Pass.getAnalysis()), VRM(VRM),
 MRI(MF.getRegInfo()), TII(*MF.getSubtarget().getInstrInfo()),
 TRI(*MF.getSubtarget().getRegisterInfo()),
 MBFI(Pass.getAnalysis()),
diff --git a/llvm/lib/CodeGen/SpillPlacement.cpp 
b/llvm/lib/CodeGen/SpillPlacement.cpp
index 6e74e51d678285b..cdb8099e354bba1 100644
--- a/llvm/lib/CodeGen/SpillPlacement.cpp
+++ b/llvm/lib/CodeGen/SpillPlacement.cpp
@@ -32,7 +32,6 @@
 #include "llvm/CodeGen/MachineBasicBlock.h"
 #include "llvm/CodeGen/MachineBlockFrequencyInfo.h"
 #include "llvm/CodeGen/MachineFunction.h"
-#include "llvm/CodeGen/MachineLoopInfo.h"
 #include "llvm/CodeGen/Passes.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Pass.h"
@@ -52,7 +51,6 @@ char &llvm::SpillPlacementID = SpillPlacement::ID;
 INITIALIZE_PASS_BEGIN(SpillPlacement, DEBUG_TYPE,
   "Spill Code Placement Analysis", true, true)
 INITIALIZE_PASS_DEPENDENCY(EdgeBundles)
-INITIALIZE_PASS_DEPENDENCY(MachineLoopInfo)
 INITIALIZE_PASS_END(SpillPlacement, DEBUG_TYPE,
 "Spill Code Placement Analysis", true, true)
 
@@ -60,7 +58,6 @@ void SpillPlacement::getAnalysisUsage(AnalysisUsage &AU) 
const {
   AU.setPreservesAll();
   AU.addRequired();
   AU.addRequiredTransitive();
-  AU.addRequiredTransitive();
   MachineFunctionPass::getAnalysisUsage(AU);
 }
 
@@ -195,7 +192,6 @@ struct SpillPlacement::Node {
 bool SpillPlacement::runOnMachineFunction(MachineFunction &mf) {
   MF = &mf;
   bundles = &getAnalysis();
-  loops = &getAnalysis();
 
   assert(!nodes && "Leaking node ar

[clang] [llvm] [clang-tools-extra] Remove unused LoopInfo from InlineSpiller and SpillPlacement (NFC) (PR #71874)

2023-11-16 Thread Matthias Braun via cfe-commits

https://github.com/MatzeB updated 
https://github.com/llvm/llvm-project/pull/71874

>From 3b502f8cc14456b325efc3017a4a114391284b37 Mon Sep 17 00:00:00 2001
From: Matthias Braun 
Date: Wed, 19 Oct 2022 10:58:40 -0700
Subject: [PATCH 1/2] Remove unused LoopInfo from InlineSpiller and
 SpillPlacement

---
 llvm/lib/CodeGen/CalcSpillWeights.cpp | 5 ++---
 llvm/lib/CodeGen/InlineSpiller.cpp| 9 ++---
 llvm/lib/CodeGen/SpillPlacement.cpp   | 4 
 llvm/lib/CodeGen/SpillPlacement.h | 2 --
 4 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/llvm/lib/CodeGen/CalcSpillWeights.cpp 
b/llvm/lib/CodeGen/CalcSpillWeights.cpp
index bf114921a7d220a..0d819e0298213b9 100644
--- a/llvm/lib/CodeGen/CalcSpillWeights.cpp
+++ b/llvm/lib/CodeGen/CalcSpillWeights.cpp
@@ -163,8 +163,6 @@ float VirtRegAuxInfo::weightCalcHelper(LiveInterval &LI, 
SlotIndex *Start,
   const TargetRegisterInfo &TRI = *MF.getSubtarget().getRegisterInfo();
   const TargetInstrInfo &TII = *MF.getSubtarget().getInstrInfo();
   MachineBasicBlock *MBB = nullptr;
-  MachineLoop *Loop = nullptr;
-  bool IsExiting = false;
   float TotalWeight = 0;
   unsigned NumInstr = 0; // Number of instructions using LI
   SmallPtrSet Visited;
@@ -260,9 +258,10 @@ float VirtRegAuxInfo::weightCalcHelper(LiveInterval &LI, 
SlotIndex *Start,
 float Weight = 1.0f;
 if (IsSpillable) {
   // Get loop info for mi.
+  bool IsExiting = false;
   if (MI->getParent() != MBB) {
 MBB = MI->getParent();
-Loop = Loops.getLoopFor(MBB);
+const MachineLoop *Loop = Loops.getLoopFor(MBB);
 IsExiting = Loop ? Loop->isLoopExiting(MBB) : false;
   }
 
diff --git a/llvm/lib/CodeGen/InlineSpiller.cpp 
b/llvm/lib/CodeGen/InlineSpiller.cpp
index 71d58b2e9e18d7d..e6d6fff96fbc519 100644
--- a/llvm/lib/CodeGen/InlineSpiller.cpp
+++ b/llvm/lib/CodeGen/InlineSpiller.cpp
@@ -33,7 +33,6 @@
 #include "llvm/CodeGen/MachineInstr.h"
 #include "llvm/CodeGen/MachineInstrBuilder.h"
 #include "llvm/CodeGen/MachineInstrBundle.h"
-#include "llvm/CodeGen/MachineLoopInfo.h"
 #include "llvm/CodeGen/MachineOperand.h"
 #include "llvm/CodeGen/MachineRegisterInfo.h"
 #include "llvm/CodeGen/SlotIndexes.h"
@@ -86,7 +85,6 @@ class HoistSpillHelper : private LiveRangeEdit::Delegate {
   LiveIntervals &LIS;
   LiveStacks &LSS;
   MachineDominatorTree &MDT;
-  MachineLoopInfo &Loops;
   VirtRegMap &VRM;
   MachineRegisterInfo &MRI;
   const TargetInstrInfo &TII;
@@ -138,8 +136,7 @@ class HoistSpillHelper : private LiveRangeEdit::Delegate {
VirtRegMap &vrm)
   : MF(mf), LIS(pass.getAnalysis()),
 LSS(pass.getAnalysis()),
-MDT(pass.getAnalysis()),
-Loops(pass.getAnalysis()), VRM(vrm),
+MDT(pass.getAnalysis()), VRM(vrm),
 MRI(mf.getRegInfo()), TII(*mf.getSubtarget().getInstrInfo()),
 TRI(*mf.getSubtarget().getRegisterInfo()),
 MBFI(pass.getAnalysis()),
@@ -157,7 +154,6 @@ class InlineSpiller : public Spiller {
   LiveIntervals &LIS;
   LiveStacks &LSS;
   MachineDominatorTree &MDT;
-  MachineLoopInfo &Loops;
   VirtRegMap &VRM;
   MachineRegisterInfo &MRI;
   const TargetInstrInfo &TII;
@@ -197,8 +193,7 @@ class InlineSpiller : public Spiller {
 VirtRegAuxInfo &VRAI)
   : MF(MF), LIS(Pass.getAnalysis()),
 LSS(Pass.getAnalysis()),
-MDT(Pass.getAnalysis()),
-Loops(Pass.getAnalysis()), VRM(VRM),
+MDT(Pass.getAnalysis()), VRM(VRM),
 MRI(MF.getRegInfo()), TII(*MF.getSubtarget().getInstrInfo()),
 TRI(*MF.getSubtarget().getRegisterInfo()),
 MBFI(Pass.getAnalysis()),
diff --git a/llvm/lib/CodeGen/SpillPlacement.cpp 
b/llvm/lib/CodeGen/SpillPlacement.cpp
index 6e74e51d678285b..cdb8099e354bba1 100644
--- a/llvm/lib/CodeGen/SpillPlacement.cpp
+++ b/llvm/lib/CodeGen/SpillPlacement.cpp
@@ -32,7 +32,6 @@
 #include "llvm/CodeGen/MachineBasicBlock.h"
 #include "llvm/CodeGen/MachineBlockFrequencyInfo.h"
 #include "llvm/CodeGen/MachineFunction.h"
-#include "llvm/CodeGen/MachineLoopInfo.h"
 #include "llvm/CodeGen/Passes.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Pass.h"
@@ -52,7 +51,6 @@ char &llvm::SpillPlacementID = SpillPlacement::ID;
 INITIALIZE_PASS_BEGIN(SpillPlacement, DEBUG_TYPE,
   "Spill Code Placement Analysis", true, true)
 INITIALIZE_PASS_DEPENDENCY(EdgeBundles)
-INITIALIZE_PASS_DEPENDENCY(MachineLoopInfo)
 INITIALIZE_PASS_END(SpillPlacement, DEBUG_TYPE,
 "Spill Code Placement Analysis", true, true)
 
@@ -60,7 +58,6 @@ void SpillPlacement::getAnalysisUsage(AnalysisUsage &AU) 
const {
   AU.setPreservesAll();
   AU.addRequired();
   AU.addRequiredTransitive();
-  AU.addRequiredTransitive();
   MachineFunctionPass::getAnalysisUsage(AU);
 }
 
@@ -195,7 +192,6 @@ struct SpillPlacement::Node {
 bool SpillPlacement::runOnMachineFunction(MachineFunction &mf) {
   MF = &mf;
   bundles = &getAnalysis();
-  loops = &getAnalysis();
 
   assert(!nodes && "Leaking no

[clang-tools-extra] [llvm] [clang] Remove unused LoopInfo from InlineSpiller and SpillPlacement (NFC) (PR #71874)

2023-11-16 Thread Matthias Braun via cfe-commits

https://github.com/MatzeB updated 
https://github.com/llvm/llvm-project/pull/71874

>From 3b502f8cc14456b325efc3017a4a114391284b37 Mon Sep 17 00:00:00 2001
From: Matthias Braun 
Date: Wed, 19 Oct 2022 10:58:40 -0700
Subject: [PATCH 1/3] Remove unused LoopInfo from InlineSpiller and
 SpillPlacement

---
 llvm/lib/CodeGen/CalcSpillWeights.cpp | 5 ++---
 llvm/lib/CodeGen/InlineSpiller.cpp| 9 ++---
 llvm/lib/CodeGen/SpillPlacement.cpp   | 4 
 llvm/lib/CodeGen/SpillPlacement.h | 2 --
 4 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/llvm/lib/CodeGen/CalcSpillWeights.cpp 
b/llvm/lib/CodeGen/CalcSpillWeights.cpp
index bf114921a7d220a..0d819e0298213b9 100644
--- a/llvm/lib/CodeGen/CalcSpillWeights.cpp
+++ b/llvm/lib/CodeGen/CalcSpillWeights.cpp
@@ -163,8 +163,6 @@ float VirtRegAuxInfo::weightCalcHelper(LiveInterval &LI, 
SlotIndex *Start,
   const TargetRegisterInfo &TRI = *MF.getSubtarget().getRegisterInfo();
   const TargetInstrInfo &TII = *MF.getSubtarget().getInstrInfo();
   MachineBasicBlock *MBB = nullptr;
-  MachineLoop *Loop = nullptr;
-  bool IsExiting = false;
   float TotalWeight = 0;
   unsigned NumInstr = 0; // Number of instructions using LI
   SmallPtrSet Visited;
@@ -260,9 +258,10 @@ float VirtRegAuxInfo::weightCalcHelper(LiveInterval &LI, 
SlotIndex *Start,
 float Weight = 1.0f;
 if (IsSpillable) {
   // Get loop info for mi.
+  bool IsExiting = false;
   if (MI->getParent() != MBB) {
 MBB = MI->getParent();
-Loop = Loops.getLoopFor(MBB);
+const MachineLoop *Loop = Loops.getLoopFor(MBB);
 IsExiting = Loop ? Loop->isLoopExiting(MBB) : false;
   }
 
diff --git a/llvm/lib/CodeGen/InlineSpiller.cpp 
b/llvm/lib/CodeGen/InlineSpiller.cpp
index 71d58b2e9e18d7d..e6d6fff96fbc519 100644
--- a/llvm/lib/CodeGen/InlineSpiller.cpp
+++ b/llvm/lib/CodeGen/InlineSpiller.cpp
@@ -33,7 +33,6 @@
 #include "llvm/CodeGen/MachineInstr.h"
 #include "llvm/CodeGen/MachineInstrBuilder.h"
 #include "llvm/CodeGen/MachineInstrBundle.h"
-#include "llvm/CodeGen/MachineLoopInfo.h"
 #include "llvm/CodeGen/MachineOperand.h"
 #include "llvm/CodeGen/MachineRegisterInfo.h"
 #include "llvm/CodeGen/SlotIndexes.h"
@@ -86,7 +85,6 @@ class HoistSpillHelper : private LiveRangeEdit::Delegate {
   LiveIntervals &LIS;
   LiveStacks &LSS;
   MachineDominatorTree &MDT;
-  MachineLoopInfo &Loops;
   VirtRegMap &VRM;
   MachineRegisterInfo &MRI;
   const TargetInstrInfo &TII;
@@ -138,8 +136,7 @@ class HoistSpillHelper : private LiveRangeEdit::Delegate {
VirtRegMap &vrm)
   : MF(mf), LIS(pass.getAnalysis()),
 LSS(pass.getAnalysis()),
-MDT(pass.getAnalysis()),
-Loops(pass.getAnalysis()), VRM(vrm),
+MDT(pass.getAnalysis()), VRM(vrm),
 MRI(mf.getRegInfo()), TII(*mf.getSubtarget().getInstrInfo()),
 TRI(*mf.getSubtarget().getRegisterInfo()),
 MBFI(pass.getAnalysis()),
@@ -157,7 +154,6 @@ class InlineSpiller : public Spiller {
   LiveIntervals &LIS;
   LiveStacks &LSS;
   MachineDominatorTree &MDT;
-  MachineLoopInfo &Loops;
   VirtRegMap &VRM;
   MachineRegisterInfo &MRI;
   const TargetInstrInfo &TII;
@@ -197,8 +193,7 @@ class InlineSpiller : public Spiller {
 VirtRegAuxInfo &VRAI)
   : MF(MF), LIS(Pass.getAnalysis()),
 LSS(Pass.getAnalysis()),
-MDT(Pass.getAnalysis()),
-Loops(Pass.getAnalysis()), VRM(VRM),
+MDT(Pass.getAnalysis()), VRM(VRM),
 MRI(MF.getRegInfo()), TII(*MF.getSubtarget().getInstrInfo()),
 TRI(*MF.getSubtarget().getRegisterInfo()),
 MBFI(Pass.getAnalysis()),
diff --git a/llvm/lib/CodeGen/SpillPlacement.cpp 
b/llvm/lib/CodeGen/SpillPlacement.cpp
index 6e74e51d678285b..cdb8099e354bba1 100644
--- a/llvm/lib/CodeGen/SpillPlacement.cpp
+++ b/llvm/lib/CodeGen/SpillPlacement.cpp
@@ -32,7 +32,6 @@
 #include "llvm/CodeGen/MachineBasicBlock.h"
 #include "llvm/CodeGen/MachineBlockFrequencyInfo.h"
 #include "llvm/CodeGen/MachineFunction.h"
-#include "llvm/CodeGen/MachineLoopInfo.h"
 #include "llvm/CodeGen/Passes.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Pass.h"
@@ -52,7 +51,6 @@ char &llvm::SpillPlacementID = SpillPlacement::ID;
 INITIALIZE_PASS_BEGIN(SpillPlacement, DEBUG_TYPE,
   "Spill Code Placement Analysis", true, true)
 INITIALIZE_PASS_DEPENDENCY(EdgeBundles)
-INITIALIZE_PASS_DEPENDENCY(MachineLoopInfo)
 INITIALIZE_PASS_END(SpillPlacement, DEBUG_TYPE,
 "Spill Code Placement Analysis", true, true)
 
@@ -60,7 +58,6 @@ void SpillPlacement::getAnalysisUsage(AnalysisUsage &AU) 
const {
   AU.setPreservesAll();
   AU.addRequired();
   AU.addRequiredTransitive();
-  AU.addRequiredTransitive();
   MachineFunctionPass::getAnalysisUsage(AU);
 }
 
@@ -195,7 +192,6 @@ struct SpillPlacement::Node {
 bool SpillPlacement::runOnMachineFunction(MachineFunction &mf) {
   MF = &mf;
   bundles = &getAnalysis();
-  loops = &getAnalysis();
 
   assert(!nodes && "Leaking no

[clang-tools-extra] [clang] [llvm] Remove unused LoopInfo from InlineSpiller and SpillPlacement (NFC) (PR #71874)

2023-11-16 Thread Matthias Braun via cfe-commits

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


[clang] [Clang] Fix finding instantiated decls for class template specializations during instantiation (PR #72346)

2023-11-20 Thread Matthias Braun via cfe-commits

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-27 Thread Matthias Braun via cfe-commits

MatzeB wrote:

And digging even deeper:
- FWIW I noticed that I only used `clang -c` as benchmark previously, should 
have used `clang -c -O3` resulting in this:
```
Old-BFI:  insn: 37,821,687,947  (baseline)
New-BFI:  insn: 38,133,312,923  +0.82%
Old-BFI, no-cold: insn: 37,423,365,184  -1.05%
New-BFI, no-cold: insn: 37,438,736,713  -1.01%
```
- The problematic part of the code that is inlined/not-inlined is actually 
marked as `LLVM_UNLIKELY` here: 
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ADT/DenseMap.h#L607
  and intuitively one would think that it is probably best to not inline `grow` 
 (as will happen with the new BFI version)
- In practice not-inlining `grow` mostly ends up being worse because of 
knock-on effects as far as I can tell. These are the inlining decisions I 
noticed for the most prominent situation:
- `grow` inlined (Old-BFI):
 - Instruction::getMetadataImpl
 -> Value::getMetadata   not inlined
 -> DenseMap::operator[] inlined
 -> DenseMap::FindAndConstruct   inlined
 -> DenseMap::InsertIntoBucket   not inlined, size
   likely too big with `grow` inlined here
 -> DenseMap::grow   inlined
- `grow` inlined (New-BFI):
 - Instruction::getMadataImpl
 -> Value::getMetadata  inlined
 -> DenseMap::operator[]inlined
 -> DenseMap::FindAndConstruct  not inlined, size
 -> DenseMap::InsertIntoBucket  inlined
 -> DenseMap::grow  not inlined
 
Though if you look into this then I would state that the code got better for 
the wrong reasons! Not inlining `grow` is a sensible decision in this context 
and the `LLVM_UNLIKELY` annotation makes sense (I actually added some counters 
and see the unlikely branch taken somewhere between 1% and 10% of the cases 
depending on inputs, so seems sensible).

Unfortunately the particular code here `getMetadataImpl` never inserts new 
things into the map, but unfortunately `operator[]` gives you that behavior by 
default so nobody noticed. So not inlining `InsertIntoBucket` happened to be a 
great decision previously that the compiler did by accident without having good 
data to support this. Now with better but still insufficient data (as this is 
PGO) we happen to make the decisions that ends up being worse.

Long story short: This ended up another of the many stories where the compiler 
cannot make the right inlining decisions without having actual runtime data. It 
tends to make a better decision based on the data that ends up being wrong 
anyway here. I'm gonna leave things as is and rather put up some improvements 
to LLVM code instead!

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


[clang] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits

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

Seems like a sensible backstop for slightly incorrect profile data leading to 
extreme branch weights. Added some nitpicks, either way LGTM

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


[clang] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits


@@ -636,9 +636,13 @@ static void updateBranchWeights(Instruction *Term, 
WeightInfo &Info) {
 MDB.createBranchWeights(Info.Weights));
   for (auto [Idx, SubWeight] : enumerate(Info.SubWeights))
 if (SubWeight != 0)
-  Info.Weights[Idx] = Info.Weights[Idx] > SubWeight
-  ? Info.Weights[Idx] - SubWeight
-  : 1;
+  // Don't set the probability of taking the edge from latch to loop header
+  // to less than 1, as this could significantly reduce the loop's hotness,
+  // which would be incorrect in the case of underestimating the trip 
count.

MatzeB wrote:

Maybe "Don't set the probability ... to less than a 1:1 ratio (meaning Weight 
should not be lower than SubWeight) ... "?

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


[clang-tools-extra] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits

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


[clang-tools-extra] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits


@@ -636,9 +636,13 @@ static void updateBranchWeights(Instruction *Term, 
WeightInfo &Info) {
 MDB.createBranchWeights(Info.Weights));
   for (auto [Idx, SubWeight] : enumerate(Info.SubWeights))
 if (SubWeight != 0)
-  Info.Weights[Idx] = Info.Weights[Idx] > SubWeight
-  ? Info.Weights[Idx] - SubWeight
-  : 1;
+  // Don't set the probability of taking the edge from latch to loop header
+  // to less than 1, as this could significantly reduce the loop's hotness,
+  // which would be incorrect in the case of underestimating the trip 
count.
+  Info.Weights[Idx] =
+  Info.Weights[Idx] > SubWeight
+  ? std::max(Info.Weights[Idx] - SubWeight, SubWeight)
+  : SubWeight;

MatzeB wrote:

```suggestion
  Info.Weights[Idx] =
  Info.Weights[Idx] > 2 * SubWeight
  ? Info.Weights[Idx] - SubWeight
  : SubWeight;
```

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


[clang-tools-extra] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits

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

Seems like a sensible backstop for slightly incorrect profile data leading to 
extreme branch weights. Added some nitpicks, either way LGTM

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


[clang-tools-extra] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits


@@ -636,9 +636,13 @@ static void updateBranchWeights(Instruction *Term, 
WeightInfo &Info) {
 MDB.createBranchWeights(Info.Weights));
   for (auto [Idx, SubWeight] : enumerate(Info.SubWeights))
 if (SubWeight != 0)
-  Info.Weights[Idx] = Info.Weights[Idx] > SubWeight
-  ? Info.Weights[Idx] - SubWeight
-  : 1;
+  // Don't set the probability of taking the edge from latch to loop header
+  // to less than 1, as this could significantly reduce the loop's hotness,
+  // which would be incorrect in the case of underestimating the trip 
count.

MatzeB wrote:

Maybe "Don't set the probability ... to less than a 1:1 ratio (meaning Weight 
should not be lower than SubWeight) ... "?

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


[clang] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits


@@ -636,9 +636,13 @@ static void updateBranchWeights(Instruction *Term, 
WeightInfo &Info) {
 MDB.createBranchWeights(Info.Weights));
   for (auto [Idx, SubWeight] : enumerate(Info.SubWeights))
 if (SubWeight != 0)
-  Info.Weights[Idx] = Info.Weights[Idx] > SubWeight
-  ? Info.Weights[Idx] - SubWeight
-  : 1;
+  // Don't set the probability of taking the edge from latch to loop header
+  // to less than 1, as this could significantly reduce the loop's hotness,
+  // which would be incorrect in the case of underestimating the trip 
count.
+  Info.Weights[Idx] =
+  Info.Weights[Idx] > SubWeight
+  ? std::max(Info.Weights[Idx] - SubWeight, SubWeight)
+  : SubWeight;

MatzeB wrote:

```suggestion
  Info.Weights[Idx] =
  Info.Weights[Idx] > 2 * SubWeight
  ? Info.Weights[Idx] - SubWeight
  : SubWeight;
```

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


[clang] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits

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


[clang] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits


@@ -636,9 +636,13 @@ static void updateBranchWeights(Instruction *Term, 
WeightInfo &Info) {
 MDB.createBranchWeights(Info.Weights));
   for (auto [Idx, SubWeight] : enumerate(Info.SubWeights))
 if (SubWeight != 0)
-  Info.Weights[Idx] = Info.Weights[Idx] > SubWeight
-  ? Info.Weights[Idx] - SubWeight
-  : 1;
+  // Don't set the probability of taking the edge from latch to loop header
+  // to less than 1, as this could significantly reduce the loop's hotness,
+  // which would be incorrect in the case of underestimating the trip 
count.
+  Info.Weights[Idx] =
+  Info.Weights[Idx] > SubWeight
+  ? std::max(Info.Weights[Idx] - SubWeight, SubWeight)
+  : SubWeight;

MatzeB wrote:

Actually this suggestion may be susceptible to overflow... So please keep your 
original `std::max` variant of the code then and ignore this!

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


[clang-tools-extra] [LoopPeeling] Fix weights updating of peeled off branches (PR #70094)

2023-10-30 Thread Matthias Braun via cfe-commits


@@ -636,9 +636,13 @@ static void updateBranchWeights(Instruction *Term, 
WeightInfo &Info) {
 MDB.createBranchWeights(Info.Weights));
   for (auto [Idx, SubWeight] : enumerate(Info.SubWeights))
 if (SubWeight != 0)
-  Info.Weights[Idx] = Info.Weights[Idx] > SubWeight
-  ? Info.Weights[Idx] - SubWeight
-  : 1;
+  // Don't set the probability of taking the edge from latch to loop header
+  // to less than 1, as this could significantly reduce the loop's hotness,
+  // which would be incorrect in the case of underestimating the trip 
count.
+  Info.Weights[Idx] =
+  Info.Weights[Idx] > SubWeight
+  ? std::max(Info.Weights[Idx] - SubWeight, SubWeight)
+  : SubWeight;

MatzeB wrote:

Actually this suggestion may be susceptible to overflow... So please keep your 
original `std::max` variant of the code then and ignore this!

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


[clang-tools-extra] [llvm] [clang] [compiler-rt] Bfi precision (PR #66285)

2023-11-01 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Do you just see regression or also some wins? I don't know whether this is all 
stems from the `isColdCallSite` behavior, and not just the usual some things 
get better some things get worse situation you can easily have when inlining 
changes?

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


[clang] [compiler-rt] [clang-tools-extra] [llvm] Bfi precision (PR #66285)

2023-11-01 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Or put another way: Do you see regressions disappear with `-mllvm 
-cold-callsite-rel-freq=0` ?

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


[clang] [llvm] [flang] [clang-tools-extra] [compiler-rt] [bpi] Reuse the AsmWriter's BB naming scheme (PR #73593)

2023-12-01 Thread Matthias Braun via cfe-commits

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

LGTM

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


[llvm] [clang] [compiler-rt] [clang-tools-extra] [flang] [bpi] Reuse the AsmWriter's BB naming scheme (PR #73593)

2023-12-01 Thread Matthias Braun via cfe-commits

https://github.com/MatzeB commented:

Consider using `utils/update_analyze_test_checks.py` to create the check 
lines...

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


[llvm] [clang] [PGO] Add ability to mark cold functions as optsize/minsize/optnone (PR #69030)

2024-01-30 Thread Matthias Braun via cfe-commits

MatzeB wrote:

How does this relate to the existing `shouldOptimizeForSize(Function&)` and 
similar APIs which appear to provide similar functionality at a first glance. 
If they are the same, then we should have a plan in place to cleanup and only 
have one system afterwards, if there are important differences, then I wouldn't 
mind some comments getting added :)

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-25 Thread Matthias Braun via cfe-commits

MatzeB wrote:

The internal services I tried here tended to slightly improve or stay neutral.

We can revert, but could you please share some details on how your clang built 
/ tested so I have a chance to address things and bring these changes back?

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-25 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Oh so this isn't even a PGO enabled build, interesting...

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


[clang] Bfi precision (PR #66285)

2023-10-25 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Oh so this isn't even a PGO enabled build, interesting...

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-26 Thread Matthias Braun via cfe-commits

MatzeB wrote:

So not sure if there is an easy fix for the regression.

We should probably have some logic that scales all BFI values when inlining to 
better accomodate the new range of frequencies so we loose less precision by 
accident. Though that won't help with the regression at hand as that would need 
for `isColdCallSite` to accidentally not work as before to get more inlining...

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-26 Thread Matthias Braun via cfe-commits

MatzeB wrote:

I think I traced the clang regression down to 
`InlineCostCallAnalyzer::isColdCallSite` returning `true` in more instances. It 
previously did not do that because of what feels more like an accidental loss 
of precision:

The example I analyzed starts out as a single-block function with a call 
resulting in this BFI:
```
 - entry: float = 1.0, int = 8
 ```
 
 It seems that when we inline calls we just scale their BFI values to the 
callsite. And given that the entry block only had a factor of `int = 8` we have 
basically no precision left on the low-end. So after inlining a bit more the 
BFI in my example looks like this:
 ```
  - entry: float = 1.0, int = 8
 - if.then.i: float = 0.0, int = 0
 - if.else.i: float = 0.0, int = 7
 - if.end15.sink.split.i: float = 0.0, int = 0
 - if.end15.i: float = 0.0, int = 8
 - if.then19.i: float = 0.0, int = 5
 - 
_ZN4llvm12DenseMapBaseINS_8DenseMapIPNS_10StructTypeEPNS_12StructLayoutENS_12DenseMapInfoIS3_vEENS_6detail12DenseMapPairIS3_S5_S3_S5_S7_SA_E20InsertIntoBucketImplIS3_EEPSA_RKS3_RKT_SE_.exit:
 float = 0.0, int = 8
 ```
 Note that some blocks frequencies got scaled down to `0`. But more importantly 
no matter what we do it is impossible to have any code marked as "cold" in this 
situation. Because the cold code threshold is computed as 2% of the entry block 
frequency. With an entry block value of `int = 8` the 2% cold-threshold is 
integer `0` and it is effectively impossible for any block to be below that 
threshold.
 
 
 In comparison with the new conversion scheme we end up with:
 ```
  - entry: float = 1.0, int = 18014398509481984
 - if.then.i: float = 0.0, int = 9002696048640
 - if.else.i: float = 0.0, int = 18005395813433344
 - if.end15.sink.split.i: float = 0.0, int = 18000892999733
 - if.end15.i: float = 0.0, int = 18014398509481984
 - if.then19.i: float = 0.0, int = 11258999068426240
 - 
_ZN4llvm12DenseMapBaseINS_8DenseMapIPNS_10StructTypeEPNS_12StructLayoutENS_12DenseMapInfoIS3_vEENS_6detail12DenseMapPairIS3_S5_S3_S5_S7_SA_E20InsertIntoBucketImplIS3_EEPSA_RKS3_RKT_SE_.exit:
 float = 0.0, int = 18014398509481984
 ```
for the same situation and blocks like `if.end15.sink.split.i` end up being 
classified as cold code now.
 

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-26 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Also note that this 2% cold-code threshold is only applied in situation where 
no PGO data is available. So maybe we should just ignore this, given that 
without PGO data it just is often impossible for the compiler to make good 
inlining decisions...

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


[clang] Bfi precision (PR #66285)

2023-10-26 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Seems this got introduced in https://reviews.llvm.org/D34312 with the rough 
idea that we shouldn't inline into parts of the code that 
`_builtin_expect(...)` deems unlikely. Which makes sense when you say it 
express it like this, but I guess numeric thresholds can go wrong...

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-26 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Seems this got introduced in https://reviews.llvm.org/D34312 with the rough 
idea that we shouldn't inline into parts of the code that 
`_builtin_expect(...)` deems unlikely. Which makes sense when you say it 
express it like this, but I guess numeric thresholds can go wrong...

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


[clang-tools-extra] Bfi precision (PR #66285)

2023-10-27 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Not sure how this change could trigger leaks. Changing BFI here should mostly 
effect inlining decisions, basic block placement, register allocation. But it 
shouldn't change program behavior or memory operations...

Will try to reproduce this test on my machine, to see if there's anything 
obvious for the change here (though at a first glance the test code seems to 
provoke an exception abort and would naturally leak because of it?)

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


[clang] Bfi precision (PR #66285)

2023-10-27 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Some very ad-hoc benchmarking. Of clang compilation speed (measured in 
instructions as reported by valgrind/callgrind which I think somewhat matches 
the setup of nikic) compiling `sqlite3` of CTMark:

Old-BFI (this PR reverted), New-BFI (this PR applied), no-cold 
(cold-callsite-rel-freq set to 0 to disable 
`InlineCostCallAnalyzer::isColdCallSite` behavior for non-PGO builds:

```
Old-BFI:  size:  59,802,772  (baseline)  insn: 2,812,833,144  (baseline)
New-BFI:  size:  60,247,076  +0.74%  insn: 2,818,639,641  +0.21%
Old-BFI, no-cold: size:  60,773,988  +1.62%  insn: 2,806,521,932  -0.22%
New-BFI, no-cold: size:  60,741,700  +1.57%  insn: 2,803,489,298  -0.33%
```

I could benchmark more with llvm-test-suite and put up a PR to disable 
cold-callsite-rel-freq by default if people support this direction...

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


[clang] cafe50d - Explicitly initialize opaque pointer mode in CodeGenAction

2022-11-07 Thread Matthias Braun via cfe-commits

Author: Matthias Braun
Date: 2022-11-07T12:31:28-08:00
New Revision: cafe50daf525971ffc3b8c5f2f6343d24e381384

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

LOG: Explicitly initialize opaque pointer mode in CodeGenAction

Explicitly call `LLVMContext::setOpaquePointers` in `CodeGenAction`
before loading any IR files. With this we use the mode specified on the
command-line rather than lazily initializing it based on the contents of
the IR.

This helps when using `-fthinlto-index` which may end up mixing files
with typed and opaque pointer types which fails when the first file
happened to use typed pointers since we cannot downgrade IR with opaque
pointer types to typed pointer types.

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

Added: 
clang/test/CodeGen/Inputs/thinlto-opaque.ll
clang/test/CodeGen/thinlto-opaque-typed-mix.ll

Modified: 
clang/lib/CodeGen/CodeGenAction.cpp
clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenAction.cpp 
b/clang/lib/CodeGen/CodeGenAction.cpp
index 52d0417a4fa6b..b723a52fbdd59 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -1102,6 +1102,8 @@ CodeGenAction::loadModule(MemoryBufferRef MBRef) {
   CompilerInstance &CI = getCompilerInstance();
   SourceManager &SM = CI.getSourceManager();
 
+  VMContext->setOpaquePointers(CI.getCodeGenOpts().OpaquePointers);
+
   // For ThinLTO backend invocations, ensure that the context
   // merges types based on ODR identifiers. We also need to read
   // the correct module out of a multi-module bitcode file.

diff  --git a/clang/test/CodeGen/Inputs/thinlto-opaque.ll 
b/clang/test/CodeGen/Inputs/thinlto-opaque.ll
new file mode 100644
index 0..bd576ab830143
--- /dev/null
+++ b/clang/test/CodeGen/Inputs/thinlto-opaque.ll
@@ -0,0 +1,6 @@
+target datalayout = 
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64--"
+
+define ptr @f2() {
+  ret ptr null
+}

diff  --git a/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll 
b/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
index 959d89d61ab27..2309ed717c2a2 100644
--- a/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
+++ b/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
@@ -100,7 +100,7 @@ cont2:
   ; CHECK-IR: br i1 {{.*}}, label %trap
 
   ; We still have to call it as virtual.
-  ; CHECK-IR: %call3 = tail call i32 %7
+  ; CHECK-IR: %call3 = tail call i32 {{%[0-9]+}}
   %call3 = tail call i32 %8(%struct.A* nonnull %obj, i32 %call)
   ret i32 %call3
 }

diff  --git a/clang/test/CodeGen/thinlto-opaque-typed-mix.ll 
b/clang/test/CodeGen/thinlto-opaque-typed-mix.ll
new file mode 100644
index 0..1cd301f290e9b
--- /dev/null
+++ b/clang/test/CodeGen/thinlto-opaque-typed-mix.ll
@@ -0,0 +1,23 @@
+; REQUIRES: x86-registered-target
+; Test that mixing bitcode file with opaque and typed pointers works.
+
+; RUN: mkdir -p %t
+; RUN: opt -module-summary -o %t/typed.bc %s
+; RUN: opt -module-summary -o %t/opaque.bc %S/Inputs/thinlto-opaque.ll
+; RUN: llvm-lto2 run -thinlto-distributed-indexes %t/typed.bc %t/opaque.bc \
+; RUN:   -o %t/native.o -r %t/typed.bc,main,plx -r %t/typed.bc,f2, \
+; RUN:   -r %t/opaque.bc,f2,p
+
+; RUN: %clang_cc1 -triple x86_64-- -emit-obj -o %t/native.o %t/typed.bc \
+; RUN:   -Wno-override-module \
+; RUN:   -fthinlto-index=%t/typed.bc.thinlto.bc
+
+target datalayout = 
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64--"
+
+declare i8* @f2()
+
+define i32 @main() {
+  call i8* @f2()
+  ret i32 0
+}



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


[clang] 850d53a - LTO: Decide upfront whether to use opaque/non-opaque pointer types

2022-06-01 Thread Matthias Braun via cfe-commits

Author: Matthias Braun
Date: 2022-06-01T18:05:53-07:00
New Revision: 850d53a197f9ffbf5708b7bd795056335e81e9b7

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

LOG: LTO: Decide upfront whether to use opaque/non-opaque pointer types

LTO code may end up mixing bitcode files from various sources varying in
their use of opaque pointer types. The current strategy to decide
between opaque / typed pointers upon the first bitcode file loaded does
not work here, since we could be loading a non-opaque bitcode file first
and would then be unable to load any files with opaque pointer types
later.

So for LTO this:
- Adds an `lto::Config::OpaquePointer` option and enforces an upfront
  decision between the two modes.
- Adds `-opaque-pointers`/`-no-opaque-pointers` options to the gold
  plugin; disabled by default.
- `--opaque-pointers`/`--no-opaque-pointers` options with
  `-plugin-opt=-opaque-pointers`/`-plugin-opt=-no-opaque-pointers`
  aliases to lld; disabled by default.
- Adds an `-lto-opaque-pointers` option to the `llvm-lto2` tool.
- Changes the clang driver to pass `-plugin-opt=-opaque-pointers` to
  the linker in LTO modes when clang was configured with opaque
  pointers enabled by default.

This fixes https://github.com/llvm/llvm-project/issues/55377

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

Added: 
clang/test/Driver/lto-no-opaque-pointers.c
clang/test/Driver/lto-opaque-pointers.c
llvm/test/LTO/X86/Inputs/opaque-pointers.ll
llvm/test/LTO/X86/mix-opaque-typed.ll

Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/CodeGen/thinlto-inline-asm2.c
clang/test/Driver/arm-float-abi-lto.c
clang/test/Driver/memtag_lto.c
lld/ELF/Config.h
lld/ELF/Driver.cpp
lld/ELF/LTO.cpp
lld/ELF/Options.td
lld/test/ELF/lto/discard-value-names.ll
lld/test/ELF/lto/ltopasses-basic.ll
lld/test/ELF/lto/type-merge.ll
lld/test/ELF/lto/type-merge2.ll
lld/test/ELF/lto/wrap-unreferenced-before-codegen.test
llvm/docs/OpaquePointers.rst
llvm/include/llvm/LTO/Config.h
llvm/test/Analysis/StackSafetyAnalysis/ipa-alias.ll
llvm/test/Analysis/StackSafetyAnalysis/ipa.ll
llvm/test/LTO/Resolution/X86/alias-alias.ll
llvm/test/LTO/Resolution/X86/comdat.ll
llvm/test/LTO/Resolution/X86/ifunc2.ll
llvm/test/LTO/Resolution/X86/local-def-dllimport.ll
llvm/test/LTO/X86/cfi_jt_aliases.ll
llvm/test/LTO/X86/type-mapping-bug4.ll
llvm/test/ThinLTO/X86/Inputs/import-constant.ll
llvm/test/ThinLTO/X86/cfi-devirt.ll
llvm/test/ThinLTO/X86/cfi-unsat.ll
llvm/test/ThinLTO/X86/devirt-after-icp.ll
llvm/test/ThinLTO/X86/devirt2.ll
llvm/test/ThinLTO/X86/devirt_check.ll
llvm/test/ThinLTO/X86/devirt_promote.ll
llvm/test/ThinLTO/X86/devirt_single_hybrid.ll
llvm/test/ThinLTO/X86/funcattrs-prop-unknown.ll
llvm/test/ThinLTO/X86/globals-import-blockaddr.ll
llvm/test/ThinLTO/X86/import-constant.ll
llvm/test/ThinLTO/X86/import-dsolocal.ll
llvm/test/ThinLTO/X86/index-const-prop-gvref-pie.ll
llvm/test/ThinLTO/X86/index-const-prop-gvref.ll
llvm/test/ThinLTO/X86/index-const-prop-linkage.ll
llvm/test/ThinLTO/X86/reference_non_importable.ll
llvm/test/ThinLTO/X86/weak_externals.ll
llvm/tools/gold/gold-plugin.cpp
llvm/tools/llvm-lto2/llvm-lto2.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 7a22ac4afa7e8..7e9fa055b0bc2 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -559,6 +559,9 @@ void tools::addLTOOptions(const ToolChain &ToolChain, const 
ArgList &Args,
 CmdArgs.push_back(
 Args.MakeArgString("-plugin-opt=jobs=" + Twine(Parallelism)));
 
+  if (!CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL)
+CmdArgs.push_back(Args.MakeArgString("-plugin-opt=no-opaque-pointers"));
+
   // If an explicit debugger tuning argument appeared, pass it along.
   if (Arg *A = Args.getLastArg(options::OPT_gTune_Group,
options::OPT_ggdbN_Group)) {

diff  --git a/clang/test/CodeGen/thinlto-inline-asm2.c 
b/clang/test/CodeGen/thinlto-inline-asm2.c
index 5d7bbc097de7c..7606b27deac87 100644
--- a/clang/test/CodeGen/thinlto-inline-asm2.c
+++ b/clang/test/CodeGen/thinlto-inline-asm2.c
@@ -5,7 +5,7 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -flto=thin -emit-llvm-bc 
%t/b.c -o %t/b.bc
 // RUN: llvm-nm %t/a.bc | FileCheck %s --check-prefix=NM
 
-// RUN: llvm-lto2 run %t/a.bc %t/b.bc -o %t/out -save-temps -r=%t/a.bc,ref,plx 
-r=%t/b.bc,ff_h264_cabac_tables,pl
+// RUN: llvm-lto2 run -lto-opaque-pointers %t/a.bc %t/b.bc -o %t/out 
-save-temps -r=%t/a.bc,ref,plx -r=%t/b.bc,ff_h264_cabac_tables,pl
 // RUN: llvm-dis

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to

MatzeB wrote:

*represent

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


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&
+!Str.getAsInteger(10, LengthOrHashCode))
+  Data = nullptr;
+  }
+
+  /// Constructor from a hash code.
+  explicit ProfileFuncRef(uint64_t HashCode)
+  : Data(nullptr), LengthOrHashCode(HashCode) {
+assert(HashCode != 0);
+  }
+
+  /// Check for equality. Similar to StringRef::equals, but will also cover for
+  /// the case where one or both are hash codes. Comparing their int values are
+  /// sufficient. A hash code ProfileFuncRef is considered not equal to a
+  /// StringRef ProfileFuncRef regardless of actual contents.
+  bool equals(const ProfileFuncRef &Other) const {
+return LengthOrHashCode == Other.LengthOrHashCode &&
+   compareMemory(Data, Other.Data, LengthOrHashCode) == 0;
+  }
+
+  /// Total order comparison. If both ProfileFuncRef are StringRef, this is the
+  /// same as StringRef::compare. If one of them is StringRef, it is considered
+  /// greater than the hash code ProfileFuncRef. Otherwise this is the the same
+  /// as comparing their int values.
+  int compare(const ProfileFuncRef &Other) const {
+auto Res = compareMemory(
+Data, Other.Data, std::min(LengthOrHashCode, Other.LengthOrHashCode));
+if (Res != 0)
+  return Res;
+if (LengthOrHashCode == Other.LengthOrHashCode)
+  return 0;
+return LengthOrHashCode < Other.LengthOrHashCode ? -1 : 1;
+  }
+
+  /// Convert to a string, usually for output purpose.
+  std::string str() const {
+if (Data)
+  return std::string(Data, LengthOrHashCode);
+if (LengthOrHashCode != 0)
+  return std::to_string(LengthOrHashCode);
+return std::string();
+  }
+
+  /// Convert to StringRef, a backing buffer must be provided in case this
+  /// object represents a hash code, which will be converted to a string into
+  /// the buffer. If this object represents a StringRef, the buffer is not 
used.
+  StringRef stringRef(std::string &Buffer) const {
+if (Data)
+  return StringRef(Data, LengthOrHashCode);
+if (Lengt

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -618,7 +623,7 @@ class SampleContext {
   void clearState(ContextStateMask S) { State &= (uint32_t)~S; }
   bool hasContext() const { return State != UnknownContext; }
   bool isBaseContext() const { return FullContext.size() == 1; }
-  StringRef getName() const { return Name; }
+  ProfileFuncRef getName() const { return Name; }

MatzeB wrote:

I guess this should be `getId()` now (or however we end up naming the 
`ProfileFuncRef` now).

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.

MatzeB wrote:

- Should use `/// @file` for documentation about a file so doxygen can pick it 
up.
- This comment seems wrong ("StringRegOrHashCode" was renamed I guess?). It 
also seems to mainly repeat what the one class in here is about.

I would suggest to simply remove the file comment (and instead make sure the 
comment on the class is good).

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&
+!Str.getAsInteger(10, LengthOrHashCode))
+  Data = nullptr;
+  }
+
+  /// Constructor from a hash code.
+  explicit ProfileFuncRef(uint64_t HashCode)
+  : Data(nullptr), LengthOrHashCode(HashCode) {
+assert(HashCode != 0);
+  }
+
+  /// Check for equality. Similar to StringRef::equals, but will also cover for
+  /// the case where one or both are hash codes. Comparing their int values are
+  /// sufficient. A hash code ProfileFuncRef is considered not equal to a
+  /// StringRef ProfileFuncRef regardless of actual contents.
+  bool equals(const ProfileFuncRef &Other) const {

MatzeB wrote:

would it make sense to call this `operator==`?

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;

MatzeB wrote:

Maybe call this `Name`?

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


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&
+!Str.getAsInteger(10, LengthOrHashCode))
+  Data = nullptr;
+  }
+
+  /// Constructor from a hash code.
+  explicit ProfileFuncRef(uint64_t HashCode)
+  : Data(nullptr), LengthOrHashCode(HashCode) {
+assert(HashCode != 0);
+  }
+
+  /// Check for equality. Similar to StringRef::equals, but will also cover for
+  /// the case where one or both are hash codes. Comparing their int values are
+  /// sufficient. A hash code ProfileFuncRef is considered not equal to a
+  /// StringRef ProfileFuncRef regardless of actual contents.
+  bool equals(const ProfileFuncRef &Other) const {
+return LengthOrHashCode == Other.LengthOrHashCode &&
+   compareMemory(Data, Other.Data, LengthOrHashCode) == 0;
+  }
+
+  /// Total order comparison. If both ProfileFuncRef are StringRef, this is the
+  /// same as StringRef::compare. If one of them is StringRef, it is considered
+  /// greater than the hash code ProfileFuncRef. Otherwise this is the the same
+  /// as comparing their int values.
+  int compare(const ProfileFuncRef &Other) const {
+auto Res = compareMemory(
+Data, Other.Data, std::min(LengthOrHashCode, Other.LengthOrHashCode));
+if (Res != 0)
+  return Res;
+if (LengthOrHashCode == Other.LengthOrHashCode)
+  return 0;
+return LengthOrHashCode < Other.LengthOrHashCode ? -1 : 1;
+  }
+
+  /// Convert to a string, usually for output purpose.
+  std::string str() const {
+if (Data)
+  return std::string(Data, LengthOrHashCode);
+if (LengthOrHashCode != 0)
+  return std::to_string(LengthOrHashCode);
+return std::string();
+  }
+
+  /// Convert to StringRef, a backing buffer must be provided in case this
+  /// object represents a hash code, which will be converted to a string into
+  /// the buffer. If this object represents a StringRef, the buffer is not 
used.
+  StringRef stringRef(std::string &Buffer) const {
+if (Data)
+  return StringRef(Data, LengthOrHashCode);
+if (Lengt

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -643,14 +648,11 @@ class SampleContext {
   uint64_t getHashCode() const {
 if (hasContext())
   return hash_value(getContextFrames());
-
-// For non-context function name, use its MD5 as hash value, so that it is
-// consistent with the profile map's key.
-return hashFuncName(getName());
+return getName().getHashCode();

MatzeB wrote:

```suggestion
return hash_value(Name);
```

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


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.

MatzeB wrote:

When using `///` for doxygen you should describe what the field does... If you 
just want to point out the datatype detail I guess it should be `//` (though 
not sure it's even necessary to explain the `uint64_t` IMO)

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {

MatzeB wrote:

maybe `FunctionIdentifier`? (The `Profile` prefix seems superfluous as this is 
already in a `SampleProf` namespace)

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


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.

MatzeB wrote:

- Should use `/// @file` for documentation about a file so doxygen can pick it 
up.
- This comment seems wrong ("StringRegOrHashCode" was renamed I guess?). It 
also seems to mainly repeat what the one class in here is about.

I would suggest to simply remove the file comment (and instead make sure the 
comment on the class is good).

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&
+!Str.getAsInteger(10, LengthOrHashCode))
+  Data = nullptr;
+  }
+
+  /// Constructor from a hash code.
+  explicit ProfileFuncRef(uint64_t HashCode)
+  : Data(nullptr), LengthOrHashCode(HashCode) {
+assert(HashCode != 0);
+  }
+
+  /// Check for equality. Similar to StringRef::equals, but will also cover for

MatzeB wrote:

Is there anything special about `StringRef::equals` that needs mentioning here? 
It's just an equality check here (and there's no actual `StringRef`s involved).

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


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&
+!Str.getAsInteger(10, LengthOrHashCode))
+  Data = nullptr;
+  }
+
+  /// Constructor from a hash code.
+  explicit ProfileFuncRef(uint64_t HashCode)
+  : Data(nullptr), LengthOrHashCode(HashCode) {
+assert(HashCode != 0);
+  }
+
+  /// Check for equality. Similar to StringRef::equals, but will also cover for
+  /// the case where one or both are hash codes. Comparing their int values are
+  /// sufficient. A hash code ProfileFuncRef is considered not equal to a
+  /// StringRef ProfileFuncRef regardless of actual contents.
+  bool equals(const ProfileFuncRef &Other) const {
+return LengthOrHashCode == Other.LengthOrHashCode &&
+   compareMemory(Data, Other.Data, LengthOrHashCode) == 0;
+  }
+
+  /// Total order comparison. If both ProfileFuncRef are StringRef, this is the
+  /// same as StringRef::compare. If one of them is StringRef, it is considered
+  /// greater than the hash code ProfileFuncRef. Otherwise this is the the same
+  /// as comparing their int values.
+  int compare(const ProfileFuncRef &Other) const {
+auto Res = compareMemory(
+Data, Other.Data, std::min(LengthOrHashCode, Other.LengthOrHashCode));
+if (Res != 0)
+  return Res;
+if (LengthOrHashCode == Other.LengthOrHashCode)
+  return 0;
+return LengthOrHashCode < Other.LengthOrHashCode ? -1 : 1;
+  }
+
+  /// Convert to a string, usually for output purpose.
+  std::string str() const {
+if (Data)
+  return std::string(Data, LengthOrHashCode);
+if (LengthOrHashCode != 0)
+  return std::to_string(LengthOrHashCode);
+return std::string();
+  }
+
+  /// Convert to StringRef, a backing buffer must be provided in case this
+  /// object represents a hash code, which will be converted to a string into
+  /// the buffer. If this object represents a StringRef, the buffer is not 
used.
+  StringRef stringRef(std::string &Buffer) const {
+if (Data)
+  return StringRef(Data, LengthOrHashCode);
+if (Lengt

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-04 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,222 @@
+//===--- ProfileFuncRef.h - Sample profile function name ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the StringRefOrHashCode class. It is to represent function
+// names in a sample profile, which can be in one of two forms - either a
+// regular string, or a 64-bit hash code.
+//
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function name that is read from a sample profile. 
It
+/// comes with two forms: a string or a hash code. For efficient storage, a
+/// sample profile may store function names as 64-bit MD5 values, so when
+/// reading the profile, this class can represnet them without converting it to
+/// a string first.
+/// When representing a hash code, we utilize the Length field to store it, and
+/// Data is set to null. When representing a string, it is same as StringRef,
+/// and can be pointer-casted as one.
+/// We disallow implicit cast to StringRef because there are too many instances
+/// that it may cause break the code, such as using it in a StringMap.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef. Check if Str is a number, which is 
generated
+  /// by converting a MD5 sample profile to a format that does not support MD5,
+  /// and if so, convert the numerical string to a hash code first. We assume
+  /// that no function name (from a profile) can be a pure number.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+// Only need to check for base 10 digits, fail faster if otherwise.
+if (Str.size() > 0 && isdigit(Str[0]) &&
+!Str.getAsInteger(10, LengthOrHashCode))
+  Data = nullptr;
+  }
+
+  /// Constructor from a hash code.
+  explicit ProfileFuncRef(uint64_t HashCode)
+  : Data(nullptr), LengthOrHashCode(HashCode) {
+assert(HashCode != 0);
+  }
+
+  /// Check for equality. Similar to StringRef::equals, but will also cover for
+  /// the case where one or both are hash codes. Comparing their int values are
+  /// sufficient. A hash code ProfileFuncRef is considered not equal to a
+  /// StringRef ProfileFuncRef regardless of actual contents.
+  bool equals(const ProfileFuncRef &Other) const {

MatzeB wrote:

would it make sense to call this `operator==`?

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-05 Thread Matthias Braun via cfe-commits


@@ -0,0 +1,215 @@
+//===--- ProfileFuncRef.h - Sample profile function reference ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+///
+/// Defines ProfileFuncRef class.
+///
+//===--===//
+
+#ifndef LLVM_PROFILEDATA_PROFILEFUNCREF_H
+#define LLVM_PROFILEDATA_PROFILEFUNCREF_H
+
+#include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+
+namespace llvm {
+namespace sampleprof {
+
+/// This class represents a function that is read from a sample profile. It
+/// comes with two forms: a string or a hash code. The latter form is the 
64-bit
+/// MD5 of the function name for efficient storage supported by ExtBinary
+/// profile format, and when reading the profile, this class can represent it
+/// without converting it to a string first.
+/// When representing a hash code, we utilize the LengthOrHashCode field to
+/// store it, and Name is set to null. When representing a string, it is same 
as
+/// StringRef.
+class ProfileFuncRef {
+
+  const char *Data = nullptr;
+
+  /// Use uint64_t instead of size_t so that it can also hold a MD5 value.
+  uint64_t LengthOrHashCode = 0;
+
+  /// Extension to memcmp to handle hash code representation. If both are hash
+  /// values, Lhs and Rhs are both null, function returns 0 (and needs an extra
+  /// comparison using getIntValue). If only one is hash code, it is considered
+  /// less than the StringRef one. Otherwise perform normal string comparison.
+  static int compareMemory(const char *Lhs, const char *Rhs, uint64_t Length) {
+if (Lhs == Rhs)
+  return 0;
+if (!Lhs)
+  return -1;
+if (!Rhs)
+  return 1;
+return ::memcmp(Lhs, Rhs, (size_t)Length);
+  }
+
+public:
+  ProfileFuncRef() = default;
+
+  /// Constructor from a StringRef.
+  explicit ProfileFuncRef(StringRef Str)
+  : Data(Str.data()), LengthOrHashCode(Str.size()) {
+if (!Str.getAsInteger(10, LengthOrHashCode))
+  Data = nullptr;

MatzeB wrote:

Could we keep the constructor simple and just initialize the `ProfileFuncRef` 
with a string and keep the "try parsing as an integer" logic to outside callers 
like need it?

This also seems to rely on function names not being a string of digits, which 
is not true on the object file level (so maybe some language or language 
feature I am not aware of my produce such names). I can also create such 
functions with the asm label extension:

```
$ cat x.cpp
void james_bond() __asm__("007");
void james_bond() {}
$ clang++ -S -o - -emit-llvm x.cpp
...
define dso_local void @"007"() #0 {
...
```



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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-05 Thread Matthias Braun via cfe-commits

MatzeB wrote:

> There are two ways ProfileFuncRef can originate (ignoring copy constructions):
> ...
So you are saying there can be hashcode `ProfileFuncRef`s coming from the 
profile, but an `llvm::Function` would always produce a string `ProfileFuncRef`?

> B - Whenever we lookup a ProflieFuncRef-keyed map, we need to make sure the 
> key we query has the same representation as the keys in the map.
But doesn't `SampleProfileReader::getSamplesFor(const Function &F)` create a 
string `ProfileFuncRef` and uses that for a lookup?

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


[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-05 Thread Matthias Braun via cfe-commits

MatzeB wrote:

> There are two ways ProfileFuncRef can originate (ignoring copy constructions):
> ...
So you are saying there can be hashcode `ProfileFuncRef`s coming from the 
profile, but an `llvm::Function` would always produce a string `ProfileFuncRef`?

> B - Whenever we lookup a ProflieFuncRef-keyed map, we need to make sure the 
> key we query has the same representation as the keys in the map.
But doesn't `SampleProfileReader::getSamplesFor(const Function &F)` create a 
string `ProfileFuncRef` and uses that for a lookup?

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-05 Thread Matthias Braun via cfe-commits

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


[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

2023-10-05 Thread Matthias Braun via cfe-commits

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


[clang] f8431a0 - Avoid running optimization passes in frontend test

2023-09-11 Thread Matthias Braun via cfe-commits

Author: Matthias Braun
Date: 2023-09-11T10:38:06-07:00
New Revision: f8431a0e4008db374dfb17a21119178fb960e334

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

LOG: Avoid running optimization passes in frontend test

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

Added: 


Modified: 
clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp

Removed: 




diff  --git a/clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp 
b/clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp
index 2583a4a84c3c3e1..a77593f5df738a8 100644
--- a/clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp
+++ b/clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp
@@ -1,14 +1,31 @@
-// RUN: %clang_cc1 -O1 -emit-llvm %s -o - -triple=x86_64-linux-gnu | FileCheck 
-DLIKELY=2000 -DUNLIKELY=1 %s
-// RUN: %clang_cc1 -O1 -emit-llvm %s -triple=x86_64-linux-gnu -mllvm 
-likely-branch-weight=99 -mllvm -unlikely-branch-weight=42 -o - | FileCheck 
-DLIKELY=99 -DUNLIKELY=42 %s
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -O1 -disable-llvm-passes -emit-llvm %s -o - 
-triple=x86_64-- | FileCheck %s
 
 extern volatile bool b;
 extern volatile int i;
 extern bool A();
 extern bool B();
 
+// CHECK-LABEL: @_Z1fv(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RETVAL:%.*]] = alloca i1, align 1
+// CHECK-NEXT:[[TMP0:%.*]] = load volatile i8, ptr @b, align 1, !tbaa 
[[TBAA2:![0-9]+]], !range [[RNG6:![0-9]+]]
+// CHECK-NEXT:[[TOBOOL:%.*]] = trunc i8 [[TMP0]] to i1
+// CHECK-NEXT:[[TOBOOL_EXPVAL:%.*]] = call i1 @llvm.expect.i1(i1 
[[TOBOOL]], i1 true)
+// CHECK-NEXT:br i1 [[TOBOOL_EXPVAL]], label [[IF_THEN:%.*]], label 
[[IF_END:%.*]]
+// CHECK:   if.then:
+// CHECK-NEXT:[[CALL:%.*]] = call noundef zeroext i1 @_Z1Av()
+// CHECK-NEXT:store i1 [[CALL]], ptr [[RETVAL]], align 1
+// CHECK-NEXT:br label [[RETURN:%.*]]
+// CHECK:   if.end:
+// CHECK-NEXT:[[CALL1:%.*]] = call noundef zeroext i1 @_Z1Bv()
+// CHECK-NEXT:store i1 [[CALL1]], ptr [[RETVAL]], align 1
+// CHECK-NEXT:br label [[RETURN]]
+// CHECK:   return:
+// CHECK-NEXT:[[TMP1:%.*]] = load i1, ptr [[RETVAL]], align 1
+// CHECK-NEXT:ret i1 [[TMP1]]
+//
 bool f() {
-  // CHECK-LABEL: define{{.*}} zeroext i1 @_Z1fv
-  // CHECK: br {{.*}} !prof ![[PROF_LIKELY:[0-9]+]]
   if (b)
 [[likely]] {
   return A();
@@ -16,9 +33,26 @@ bool f() {
   return B();
 }
 
+// CHECK-LABEL: @_Z1gv(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RETVAL:%.*]] = alloca i1, align 1
+// CHECK-NEXT:[[TMP0:%.*]] = load volatile i8, ptr @b, align 1, !tbaa 
[[TBAA2]], !range [[RNG6]]
+// CHECK-NEXT:[[TOBOOL:%.*]] = trunc i8 [[TMP0]] to i1
+// CHECK-NEXT:[[TOBOOL_EXPVAL:%.*]] = call i1 @llvm.expect.i1(i1 
[[TOBOOL]], i1 false)
+// CHECK-NEXT:br i1 [[TOBOOL_EXPVAL]], label [[IF_THEN:%.*]], label 
[[IF_END:%.*]]
+// CHECK:   if.then:
+// CHECK-NEXT:[[CALL:%.*]] = call noundef zeroext i1 @_Z1Av()
+// CHECK-NEXT:store i1 [[CALL]], ptr [[RETVAL]], align 1
+// CHECK-NEXT:br label [[RETURN:%.*]]
+// CHECK:   if.end:
+// CHECK-NEXT:[[CALL1:%.*]] = call noundef zeroext i1 @_Z1Bv()
+// CHECK-NEXT:store i1 [[CALL1]], ptr [[RETVAL]], align 1
+// CHECK-NEXT:br label [[RETURN]]
+// CHECK:   return:
+// CHECK-NEXT:[[TMP1:%.*]] = load i1, ptr [[RETVAL]], align 1
+// CHECK-NEXT:ret i1 [[TMP1]]
+//
 bool g() {
-  // CHECK-LABEL: define{{.*}} zeroext i1 @_Z1gv
-  // CHECK: br {{.*}} !prof ![[PROF_UNLIKELY:[0-9]+]]
   if (b)
 [[unlikely]] {
   return A();
@@ -27,18 +61,47 @@ bool g() {
   return B();
 }
 
+// CHECK-LABEL: @_Z1hv(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RETVAL:%.*]] = alloca i1, align 1
+// CHECK-NEXT:[[TMP0:%.*]] = load volatile i8, ptr @b, align 1, !tbaa 
[[TBAA2]], !range [[RNG6]]
+// CHECK-NEXT:[[TOBOOL:%.*]] = trunc i8 [[TMP0]] to i1
+// CHECK-NEXT:[[TOBOOL_EXPVAL:%.*]] = call i1 @llvm.expect.i1(i1 
[[TOBOOL]], i1 false)
+// CHECK-NEXT:br i1 [[TOBOOL_EXPVAL]], label [[IF_THEN:%.*]], label 
[[IF_END:%.*]]
+// CHECK:   if.then:
+// CHECK-NEXT:[[CALL:%.*]] = call noundef zeroext i1 @_Z1Av()
+// CHECK-NEXT:store i1 [[CALL]], ptr [[RETVAL]], align 1
+// CHECK-NEXT:br label [[RETURN:%.*]]
+// CHECK:   if.end:
+// CHECK-NEXT:[[CALL1:%.*]] = call noundef zeroext i1 @_Z1Bv()
+// CHECK-NEXT:store i1 [[CALL1]], ptr [[RETVAL]], align 1
+// CHECK-NEXT:br label [[RETURN]]
+// CHECK:   return:
+// CHECK-NEXT:[[TMP1:%.*]] = load i1, ptr [[RETVAL]], align 1
+// CHECK-NEXT:ret i1 [[TMP1]]
+//
 bool h() {
-  // CHECK-LABEL: define{{.*}} zeroext i1 @_Z1hv
-  // CHECK: br {{.*}} !prof ![[PROF_UNLIKELY]]
   if (b)
 [[unlikely]] return A(

[clang] e00a8d0 - Fix codegen for coroutine with function-try-block

2023-03-30 Thread Matthias Braun via cfe-commits

Author: Matthias Braun
Date: 2023-03-30T11:16:32-07:00
New Revision: e00a8d081d789cac606cf0749c332c4632132820

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

LOG: Fix codegen for coroutine with function-try-block

This fixes an assertion error when writing a coroutine with a
function-try-block. In this case the function body is not a
`CompoundStmt` so the code constructing an artificial CXXTryStmt must
also construct a `CompoundStmt` for it.

While on it adjust the `CXXStmt::Create` function to only accept
`CompoundStmt*`.

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

Added: 
clang/test/CodeGenCoroutines/coro-function-try-block.cpp

Modified: 
clang/include/clang/AST/StmtCXX.h
clang/lib/AST/ASTImporter.cpp
clang/lib/AST/StmtCXX.cpp
clang/lib/CodeGen/CGCoroutine.cpp
clang/lib/Sema/SemaStmt.cpp

Removed: 




diff  --git a/clang/include/clang/AST/StmtCXX.h 
b/clang/include/clang/AST/StmtCXX.h
index 8ba667c02fc09..288ffc28f40ee 100644
--- a/clang/include/clang/AST/StmtCXX.h
+++ b/clang/include/clang/AST/StmtCXX.h
@@ -75,7 +75,8 @@ class CXXTryStmt final : public Stmt,
   unsigned NumHandlers;
   size_t numTrailingObjects(OverloadToken) const { return NumHandlers; 
}
 
-  CXXTryStmt(SourceLocation tryLoc, Stmt *tryBlock, ArrayRef handlers);
+  CXXTryStmt(SourceLocation tryLoc, CompoundStmt *tryBlock,
+ ArrayRef handlers);
   CXXTryStmt(EmptyShell Empty, unsigned numHandlers)
 : Stmt(CXXTryStmtClass), NumHandlers(numHandlers) { }
 
@@ -84,7 +85,7 @@ class CXXTryStmt final : public Stmt,
 
 public:
   static CXXTryStmt *Create(const ASTContext &C, SourceLocation tryLoc,
-Stmt *tryBlock, ArrayRef handlers);
+CompoundStmt *tryBlock, ArrayRef handlers);
 
   static CXXTryStmt *Create(const ASTContext &C, EmptyShell Empty,
 unsigned numHandlers);

diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index db6ebbb8992b7..71208029fe2dd 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -6793,8 +6793,8 @@ ExpectedStmt ASTNodeImporter::VisitCXXTryStmt(CXXTryStmt 
*S) {
   return ToHandlerOrErr.takeError();
   }
 
-  return CXXTryStmt::Create(
-  Importer.getToContext(), *ToTryLocOrErr,*ToTryBlockOrErr, ToHandlers);
+  return CXXTryStmt::Create(Importer.getToContext(), *ToTryLocOrErr,
+cast(*ToTryBlockOrErr), ToHandlers);
 }
 
 ExpectedStmt ASTNodeImporter::VisitCXXForRangeStmt(CXXForRangeStmt *S) {

diff  --git a/clang/lib/AST/StmtCXX.cpp b/clang/lib/AST/StmtCXX.cpp
index a3ae5392f54bc..0d6fc848f7396 100644
--- a/clang/lib/AST/StmtCXX.cpp
+++ b/clang/lib/AST/StmtCXX.cpp
@@ -23,7 +23,8 @@ QualType CXXCatchStmt::getCaughtType() const {
 }
 
 CXXTryStmt *CXXTryStmt::Create(const ASTContext &C, SourceLocation tryLoc,
-   Stmt *tryBlock, ArrayRef handlers) {
+   CompoundStmt *tryBlock,
+   ArrayRef handlers) {
   const size_t Size = totalSizeToAlloc(handlers.size() + 1);
   void *Mem = C.Allocate(Size, alignof(CXXTryStmt));
   return new (Mem) CXXTryStmt(tryLoc, tryBlock, handlers);
@@ -36,7 +37,7 @@ CXXTryStmt *CXXTryStmt::Create(const ASTContext &C, 
EmptyShell Empty,
   return new (Mem) CXXTryStmt(Empty, numHandlers);
 }
 
-CXXTryStmt::CXXTryStmt(SourceLocation tryLoc, Stmt *tryBlock,
+CXXTryStmt::CXXTryStmt(SourceLocation tryLoc, CompoundStmt *tryBlock,
ArrayRef handlers)
 : Stmt(CXXTryStmtClass), TryLoc(tryLoc), NumHandlers(handlers.size()) {
   Stmt **Stmts = getStmts();

diff  --git a/clang/lib/CodeGen/CGCoroutine.cpp 
b/clang/lib/CodeGen/CGCoroutine.cpp
index da3da5e600104..90ab82ed88a11 100644
--- a/clang/lib/CodeGen/CGCoroutine.cpp
+++ b/clang/lib/CodeGen/CGCoroutine.cpp
@@ -593,6 +593,18 @@ static void emitBodyAndFallthrough(CodeGenFunction &CGF,
   CGF.EmitStmt(OnFallthrough);
 }
 
+static CompoundStmt *CoroutineStmtBuilder(ASTContext &Context,
+  const CoroutineBodyStmt &S) {
+  Stmt *Stmt = S.getBody();
+  if (CompoundStmt *Body = dyn_cast(Stmt))
+return Body;
+  // We are about to create a `CXXTryStmt` which requires a `CompoundStmt`.
+  // If the function body is not a `CompoundStmt` yet then we have to create
+  // a new one. This happens for cases like the "function-try-block" syntax.
+  return CompoundStmt::Create(Context, {Stmt}, FPOptionsOverride(),
+  SourceLocation(), SourceLocation());
+}
+
 void CodeGenFunction::EmitCoroutineBody(const CoroutineBodyStmt &S) {
   auto *NullPtr = llvm::ConstantPointerNull::get(Builder.getInt8PtrTy());
   auto &TI = CGM.getContext().getTarge

[clang-tools-extra] c21378f - [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions

2023-02-23 Thread Matthias Braun via cfe-commits

Author: Matthias Braun
Date: 2023-02-23T11:26:41-08:00
New Revision: c21378f90a4442810adc4af924a83a9c222fdc51

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

LOG: [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions

It seems newer grpc / protobuf versions renamed
`Status::error_message()` and `Status::error_code()` to `message()` and
`code()` to prepare for replacement with `absl::Status` with the same
names.

As far as I can tell the new names are already available in the
grpc-1.36 version mentioned in the `README` file.

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

Added: 


Modified: 
clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp 
b/clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp
index 96451f7764675..9a58b5871bfce 100644
--- a/clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp
+++ b/clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp
@@ -67,8 +67,9 @@ int main(int argc, char *argv[]) {
   google::protobuf::util::MessageToJsonString(Response, &Output, Options);
   if (!JsonStatus.ok()) {
 clang::clangd::elog("Can not convert response ({0}) to JSON ({1}): {2}\n",
-Response.DebugString(), JsonStatus.error_code(),
-JsonStatus.error_message().as_string());
+Response.DebugString(),
+static_cast(JsonStatus.code()),
+JsonStatus.message().as_string());
 return -1;
   }
   llvm::outs() << Output;



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


r291576 - CGDecl: Skip static variable initializers in unreachable code

2017-01-10 Thread Matthias Braun via cfe-commits
Author: matze
Date: Tue Jan 10 11:43:01 2017
New Revision: 291576

URL: http://llvm.org/viewvc/llvm-project?rev=291576&view=rev
Log:
CGDecl: Skip static variable initializers in unreachable code

This fixes http://llvm.org/PR31054

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

Added:
cfe/trunk/test/CodeGenCXX/pr31054.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=291576&r1=291575&r2=291576&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Jan 10 11:43:01 2017
@@ -311,7 +311,7 @@ CodeGenFunction::AddInitializerToStaticV
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@ CodeGenFunction::AddInitializerToStaticV
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.

Added: cfe/trunk/test/CodeGenCXX/pr31054.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pr31054.cpp?rev=291576&view=auto
==
--- cfe/trunk/test/CodeGenCXX/pr31054.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/pr31054.cpp Tue Jan 10 11:43:01 2017
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }


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


Re: [PATCH] D20561: Warn when taking address of packed member

2016-08-15 Thread Matthias Braun via cfe-commits
MatzeB added a subscriber: MatzeB.
MatzeB added a comment.

The sanitizer code triggers this warning for code that looks conceptually like 
this:

  typedef struct Bla { char bar; int foo; } __attribute__((packed));
  
  uintptr_t getu(struct Bla *b) { return (uintptr_t)&b->foo; }

Resulting in:

  taking address of packed member 'foo' of class or structure
'Bla' may result in an unaligned pointer value
[-Waddress-of-packed-member]

Of course the warning can be silenced with `return (uintptr_t)(char*)&b->foo;` 
still casting to an int type seems like a benign case for this warning so maybe 
we should exclude that?


Repository:
  rL LLVM

https://reviews.llvm.org/D20561



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


r293364 - Avoid calling dump() in normal code

2017-01-27 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Jan 27 20:36:00 2017
New Revision: 293364

URL: http://llvm.org/viewvc/llvm-project?rev=293364&view=rev
Log:
Avoid calling dump() in normal code

dump() is only available in debug builds and meant for debugger usage,
normal code should use something like print(errs());

Modified:
cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Modified: cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp?rev=293364&r1=293363&r2=293364&view=diff
==
--- cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp (original)
+++ cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp Fri Jan 27 
20:36:00 2017
@@ -514,7 +514,10 @@ public:
 // Dump the contents of the temporary file if that was requested.
 if (DumpTemporaryFiles) {
   errs() << ";\n; Object file bundler IR file.\n;\n";
-  AuxModule.get()->dump();
+  AuxModule.get()->print(errs(), nullptr,
+ /*ShouldPreserveUseListOrder=*/false,
+ /*IsForDebug=*/true);
+  errs() << '\n';
 }
 
 // Find clang in order to create the bundle binary.


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


r294065 - Driver: Do not warn about unused -pthread when linking on darwin

2017-02-03 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Feb  3 17:09:31 2017
New Revision: 294065

URL: http://llvm.org/viewvc/llvm-project?rev=294065&view=rev
Log:
Driver: Do not warn about unused -pthread when linking on darwin

While there is nothing to do at link time to get pthreads support on
darwin, specifying the argument is fine and we should not warn about
unused arguments.

Added:
cfe/trunk/test/Driver/darwin-ld-pthread.c
Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=294065&r1=294064&r2=294065&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Feb  3 17:09:31 2017
@@ -8696,6 +8696,10 @@ void darwin::Linker::ConstructJob(Compil
 
 // Let the tool chain choose which runtime library to link.
 getMachOToolChain().AddLinkRuntimeLibArgs(Args, CmdArgs);
+
+// No need to do anything for pthreads. Claim argument to avoid warning.
+Args.ClaimAllArgs(options::OPT_pthread);
+Args.ClaimAllArgs(options::OPT_pthreads);
   }
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {

Added: cfe/trunk/test/Driver/darwin-ld-pthread.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-ld-pthread.c?rev=294065&view=auto
==
--- cfe/trunk/test/Driver/darwin-ld-pthread.c (added)
+++ cfe/trunk/test/Driver/darwin-ld-pthread.c Fri Feb  3 17:09:31 2017
@@ -0,0 +1,4 @@
+// RUN: %clang -Wunused-command-line-argument -pthread -target 
x86_64-apple-darwin -### /dev/null -o /dev/null 2>&1 | FileCheck %s
+
+// There is nothing to do at link time to get pthread support. But do not warn.
+// CHECK-NOT: argument unused during compilation: '-pthread'


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


r308071 - Try to fix modules build

2017-07-14 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Jul 14 17:29:25 2017
New Revision: 308071

URL: http://llvm.org/viewvc/llvm-project?rev=308071&view=rev
Log:
Try to fix modules build

Module builds somehow report an ambiguity between clang::Diagnostic and
clang::Tooling::Diagnostic. It seems as if one of the additional headers
brought in by the module brings the clang namespace to the toplevel. I
could not find out the reason for that, so for now I go with the simple
fix to bring the build back to green.

rdar://33321397

Modified:
cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp

Modified: cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp?rev=308071&r1=308070&r2=308071&view=diff
==
--- cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp Fri Jul 14 17:29:25 2017
@@ -18,6 +18,7 @@
 
 using namespace llvm;
 using namespace clang::tooling;
+using clang::tooling::Diagnostic;
 
 static Diagnostic makeDiagnostic(StringRef DiagnosticName,
  const std::string &Message, int FileOffset,


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


r287371 - Adapt to llvm NamedRegionTimer changes

2016-11-18 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Nov 18 13:43:25 2016
New Revision: 287371

URL: http://llvm.org/viewvc/llvm-project?rev=287371&view=rev
Log:
Adapt to llvm NamedRegionTimer changes

We have to specify a name and description for the timers and groups now.

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=287371&r1=287370&r2=287371&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Fri Nov 18 13:43:25 2016
@@ -102,7 +102,7 @@ public:
  const clang::TargetOptions &TOpts,
  const LangOptions &LOpts, Module *M)
   : Diags(_Diags), CodeGenOpts(CGOpts), TargetOpts(TOpts), LangOpts(LOpts),
-TheModule(M), CodeGenerationTime("Code Generation Time") {}
+TheModule(M), CodeGenerationTime("codegen", "Code Generation Time") {}
 
   ~EmitAssemblyHelper() {
 if (CodeGenOpts.DisableFree)

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=287371&r1=287370&r2=287371&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Fri Nov 18 13:43:25 2016
@@ -75,7 +75,7 @@ namespace clang {
 : Diags(Diags), Action(Action), CodeGenOpts(CodeGenOpts),
   TargetOpts(TargetOpts), LangOpts(LangOpts),
   AsmOutStream(std::move(OS)), Context(nullptr),
-  LLVMIRGeneration("LLVM IR Generation Time"),
+  LLVMIRGeneration("irgen", "LLVM IR Generation Time"),
   LLVMIRGenerationRefCount(0),
   Gen(CreateLLVMCodeGen(Diags, InFile, HeaderSearchOpts, PPOpts,
 CodeGenOpts, C, CoverageInfo)) {

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=287371&r1=287370&r2=287371&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Fri Nov 18 13:43:25 2016
@@ -522,9 +522,11 @@ void CompilerInstance::createCodeComplet
 }
 
 void CompilerInstance::createFrontendTimer() {
-  FrontendTimerGroup.reset(new llvm::TimerGroup("Clang front-end time 
report"));
+  FrontendTimerGroup.reset(
+  new llvm::TimerGroup("frontend", "Clang front-end time report"));
   FrontendTimer.reset(
-  new llvm::Timer("Clang front-end timer", *FrontendTimerGroup));
+  new llvm::Timer("frontend", "Clang front-end timer",
+  *FrontendTimerGroup));
 }
 
 CodeCompleteConsumer *
@@ -1324,7 +1326,8 @@ void CompilerInstance::createModuleManag
 const PreprocessorOptions &PPOpts = getPreprocessorOpts();
 std::unique_ptr ReadTimer;
 if (FrontendTimerGroup)
-  ReadTimer = llvm::make_unique("Reading modules",
+  ReadTimer = llvm::make_unique("reading_modules",
+ "Reading modules",
  *FrontendTimerGroup);
 ModuleManager = new ASTReader(
 getPreprocessor(), getASTContext(), getPCHContainerReader(),
@@ -1357,7 +1360,8 @@ void CompilerInstance::createModuleManag
 bool CompilerInstance::loadModuleFile(StringRef FileName) {
   llvm::Timer Timer;
   if (FrontendTimerGroup)
-Timer.init("Preloading " + FileName.str(), *FrontendTimerGroup);
+Timer.init("preloading." + FileName.str(), "Preloading " + FileName.str(),
+   *FrontendTimerGroup);
   llvm::TimeRegion TimeLoading(FrontendTimerGroup ? &Timer : nullptr);
 
   // Helper to recursively read the module names for all modules we're adding.
@@ -1509,7 +1513,8 @@ CompilerInstance::loadModule(SourceLocat
 
 llvm::Timer Timer;
 if (FrontendTimerGroup)
-  Timer.init("Loading " + ModuleFileName, *FrontendTimerGroup);
+  Timer.init("loading." + ModuleFileName, "Loading " + ModuleFileName,
+ *FrontendTimerGroup);
 llvm::TimeRegion TimeLoading(FrontendTimerGroup ? &Timer : nullptr);
 
 // Try to load the module file. If we are trying to load from the prebuilt

Modified: cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp?rev=287371&r1=287370&r2=287371&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Fro

r288614 - TableGen: Adapt to llvm r288612

2016-12-03 Thread Matthias Braun via cfe-commits
Author: matze
Date: Sat Dec  3 23:55:09 2016
New Revision: 288614

URL: http://llvm.org/viewvc/llvm-project?rev=288614&view=rev
Log:
TableGen: Adapt to llvm r288612

Modified:
cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp
cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp

Modified: cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp?rev=288614&r1=288613&r2=288614&view=diff
==
--- cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp Sat Dec  3 23:55:09 2016
@@ -47,7 +47,7 @@ class ClangASTNodesEmitter {
 if (&R == &Root && !BaseSuffix.empty())
   return BaseSuffix;
 
-return R.getName() + BaseSuffix;
+return R.getName().str() + BaseSuffix;
   }
 
   std::pair EmitNode (const ChildMap &Tree, raw_ostream& 
OS,

Modified: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?rev=288614&r1=288613&r2=288614&view=diff
==
--- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp Sat Dec  3 23:55:09 2016
@@ -2695,7 +2695,7 @@ static std::string GetSubjectWithSuffix(
 
 static std::string GenerateCustomAppertainsTo(const Record &Subject,
   raw_ostream &OS) {
-  std::string FnName = "is" + Subject.getName();
+  std::string FnName = "is" + Subject.getName().str();
 
   // If this code has already been generated, simply return the previous
   // instance of it.
@@ -2744,7 +2744,7 @@ static std::string GenerateAppertainsTo(
   // Otherwise, generate an appertainsTo check specific to this attribute which
   // checks all of the given subjects against the Decl passed in. Return the
   // name of that check to the caller.
-  std::string FnName = "check" + Attr.getName() + "AppertainsTo";
+  std::string FnName = "check" + Attr.getName().str() + "AppertainsTo";
   std::stringstream SS;
   SS << "static bool " << FnName << "(Sema &S, const AttributeList &Attr, ";
   SS << "const Decl *D) {\n";
@@ -2915,7 +2915,7 @@ static std::string GenerateSpellingIndex
   // Generate the enumeration we will use for the mapping.
   SemanticSpellingMap SemanticToSyntacticMap;
   std::string Enum = CreateSemanticSpellings(Spellings, 
SemanticToSyntacticMap);
-  std::string Name = Attr.getName() + "AttrSpellingMap";
+  std::string Name = Attr.getName().str() + "AttrSpellingMap";
 
   OS << "static unsigned " << Name << "(const AttributeList &Attr) {\n";
   OS << Enum;


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


r288645 - Adapt to llvm/TableGen DagInit changes.

2016-12-04 Thread Matthias Braun via cfe-commits
Author: matze
Date: Mon Dec  5 00:00:51 2016
New Revision: 288645

URL: http://llvm.org/viewvc/llvm-project?rev=288645&view=rev
Log:
Adapt to llvm/TableGen DagInit changes.

Modified:
cfe/trunk/utils/TableGen/NeonEmitter.cpp

Modified: cfe/trunk/utils/TableGen/NeonEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/NeonEmitter.cpp?rev=288645&r1=288644&r2=288645&view=diff
==
--- cfe/trunk/utils/TableGen/NeonEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/NeonEmitter.cpp Mon Dec  5 00:00:51 2016
@@ -1478,14 +1478,14 @@ std::pair Intrinsic::
   if (DI->getNumArgs() == 2) {
 // Unary op.
 std::pair R =
-emitDagArg(DI->getArg(1), DI->getArgName(1));
+emitDagArg(DI->getArg(1), DI->getArgNameStr(1));
 return std::make_pair(R.first, Op + R.second);
   } else {
 assert(DI->getNumArgs() == 3 && "Can only handle unary and binary ops!");
 std::pair R1 =
-emitDagArg(DI->getArg(1), DI->getArgName(1));
+emitDagArg(DI->getArg(1), DI->getArgNameStr(1));
 std::pair R2 =
-emitDagArg(DI->getArg(2), DI->getArgName(2));
+emitDagArg(DI->getArg(2), DI->getArgNameStr(2));
 assert_with_loc(R1.first == R2.first, "Argument type mismatch!");
 return std::make_pair(R1.first, R1.second + " " + Op + " " + R2.second);
   }
@@ -1496,7 +1496,7 @@ std::pair Intrinsic::
   std::vector Values;
   for (unsigned I = 0; I < DI->getNumArgs() - 1; ++I) {
 std::pair R =
-emitDagArg(DI->getArg(I + 1), DI->getArgName(I + 1));
+emitDagArg(DI->getArg(I + 1), DI->getArgNameStr(I + 1));
 Types.push_back(R.first);
 Values.push_back(R.second);
   }
@@ -1529,7 +1529,8 @@ std::pair Intrinsic::
 bool 
IsBitCast){
   // (cast MOD* VAL) -> cast VAL to type given by MOD.
   std::pair R = emitDagArg(
-  DI->getArg(DI->getNumArgs() - 1), DI->getArgName(DI->getNumArgs() - 1));
+  DI->getArg(DI->getNumArgs() - 1),
+  DI->getArgNameStr(DI->getNumArgs() - 1));
   Type castToType = R.first;
   for (unsigned ArgIdx = 0; ArgIdx < DI->getNumArgs() - 1; ++ArgIdx) {
 
@@ -1540,11 +1541,11 @@ std::pair Intrinsic::
 //   4. The value "U" or "S" to switch the signedness.
 //   5. The value "H" or "D" to half or double the bitwidth.
 //   6. The value "8" to convert to 8-bit (signed) integer lanes.
-if (!DI->getArgName(ArgIdx).empty()) {
-  assert_with_loc(Intr.Variables.find(DI->getArgName(ArgIdx)) !=
+if (!DI->getArgNameStr(ArgIdx).empty()) {
+  assert_with_loc(Intr.Variables.find(DI->getArgNameStr(ArgIdx)) !=
   Intr.Variables.end(),
   "Variable not found");
-  castToType = Intr.Variables[DI->getArgName(ArgIdx)].getType();
+  castToType = Intr.Variables[DI->getArgNameStr(ArgIdx)].getType();
 } else {
   StringInit *SI = dyn_cast(DI->getArg(ArgIdx));
   assert_with_loc(SI, "Expected string type or $Name for cast type");
@@ -1659,9 +1660,9 @@ std::pair Intrinsic::
 
   // (shuffle arg1, arg2, sequence)
   std::pair Arg1 =
-  emitDagArg(DI->getArg(0), DI->getArgName(0));
+  emitDagArg(DI->getArg(0), DI->getArgNameStr(0));
   std::pair Arg2 =
-  emitDagArg(DI->getArg(1), DI->getArgName(1));
+  emitDagArg(DI->getArg(1), DI->getArgNameStr(1));
   assert_with_loc(Arg1.first == Arg2.first,
   "Different types in arguments to shuffle!");
 
@@ -1703,7 +1704,8 @@ std::pair Intrinsic::
 
 std::pair Intrinsic::DagEmitter::emitDagDup(DagInit *DI) {
   assert_with_loc(DI->getNumArgs() == 1, "dup() expects one argument");
-  std::pair A = emitDagArg(DI->getArg(0), 
DI->getArgName(0));
+  std::pair A = emitDagArg(DI->getArg(0),
+  DI->getArgNameStr(0));
   assert_with_loc(A.first.isScalar(), "dup() expects a scalar argument");
 
   Type T = Intr.getBaseType();
@@ -1721,8 +1723,10 @@ std::pair Intrinsic::
 
 std::pair Intrinsic::DagEmitter::emitDagSplat(DagInit *DI) {
   assert_with_loc(DI->getNumArgs() == 2, "splat() expects two arguments");
-  std::pair A = emitDagArg(DI->getArg(0), 
DI->getArgName(0));
-  std::pair B = emitDagArg(DI->getArg(1), 
DI->getArgName(1));
+  std::pair A = emitDagArg(DI->getArg(0),
+  DI->getArgNameStr(0));
+  std::pair B = emitDagArg(DI->getArg(1),
+  DI->getArgNameStr(1));
 
   assert_with_loc(B.first.isScalar(),
   "splat() requires a scalar int as the second argument");
@@ -1738,12 +1742,13 @@ std::pair Intrinsic::
 
 std::pair Intrinsic::DagEmitter::emitDagSaveTemp(DagInit 
*DI) {
   assert_with_loc(DI->getNumArgs() == 2, "save_temp() expects two arguments");
-  std::pair A = emitDagArg(DI->getArg(1), 
DI->getArgName(1));
+  std::pair A = emitDagArg(DI->getArg(1),
+  

r301218 - Pragma: Fix DebugOverflowStack() resulting in endless loop.

2017-04-24 Thread Matthias Braun via cfe-commits
Author: matze
Date: Mon Apr 24 13:41:00 2017
New Revision: 301218

URL: http://llvm.org/viewvc/llvm-project?rev=301218&view=rev
Log:
Pragma: Fix DebugOverflowStack() resulting in endless loop.

Drive-by fix (noticed while working on https://reviews.llvm.org/D32205):
DebugOverflowStack() is supposed to provoke a stack overflow, however
LLVM was smart enough to use the red-zone and fold the load into a tail
jump on x86_64 optimizing this to an endless loop instead of a stack
overflow.

Modified:
cfe/trunk/lib/Lex/Pragma.cpp

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=301218&r1=301217&r2=301218&view=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Mon Apr 24 13:41:00 2017
@@ -989,9 +989,9 @@ struct PragmaDebugHandler : public Pragm
 #ifdef _MSC_VER
 #pragma warning(disable : 4717)
 #endif
-  static void DebugOverflowStack() {
-void (*volatile Self)() = DebugOverflowStack;
-Self();
+  static void DebugOverflowStack(void (*P)() = nullptr) {
+void (*volatile Self)(void(*P)()) = DebugOverflowStack;
+Self(reinterpret_cast(Self));
   }
 #ifdef _MSC_VER
 #pragma warning(default : 4717)


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


r303463 - CodeGenModule: Always output wchar_size, check LLVM assumptions.

2017-05-19 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri May 19 17:37:15 2017
New Revision: 303463

URL: http://llvm.org/viewvc/llvm-project?rev=303463&view=rev
Log:
CodeGenModule: Always output wchar_size, check LLVM assumptions.

llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.

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

Added:
cfe/trunk/test/CodeGen/wchar-size.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=303463&r1=303462&r2=303463&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri May 19 17:37:15 2017
@@ -45,6 +45,7 @@
 #include "clang/Frontend/CodeGenOptions.h"
 #include "clang/Sema/SemaDiagnostic.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/CallSite.h"
 #include "llvm/IR/CallingConv.h"
 #include "llvm/IR/DataLayout.h"
@@ -465,18 +466,24 @@ void CodeGenModule::Release() {
 getModule().addModuleFlag(llvm::Module::Warning, "Debug Info Version",
   llvm::DEBUG_METADATA_VERSION);
 
+  // Width of wchar_t in bytes
+  uint64_t WCharWidth =
+  Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
+  assert(LangOpts.ShortWChar ||
+ llvm::TargetLibraryInfoImpl::getTargetWCharSize(Target.getTriple()) ==
+ Target.getWCharWidth() / 8 &&
+ "LLVM wchar_t size out of sync");
+
   // We need to record the widths of enums and wchar_t, so that we can generate
-  // the correct build attributes in the ARM backend.
+  // the correct build attributes in the ARM backend. wchar_size is also used 
by
+  // TargetLibraryInfo.
+  getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
+
   llvm::Triple::ArchType Arch = Context.getTargetInfo().getTriple().getArch();
   if (   Arch == llvm::Triple::arm
   || Arch == llvm::Triple::armeb
   || Arch == llvm::Triple::thumb
   || Arch == llvm::Triple::thumbeb) {
-// Width of wchar_t in bytes
-uint64_t WCharWidth =
-Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
-getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
-
 // The minimum width of an enum in bytes
 uint64_t EnumWidth = Context.getLangOpts().ShortEnums ? 1 : 4;
 getModule().addModuleFlag(llvm::Module::Error, "min_enum_size", EnumWidth);

Added: cfe/trunk/test/CodeGen/wchar-size.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/wchar-size.c?rev=303463&view=auto
==
--- cfe/trunk/test/CodeGen/wchar-size.c (added)
+++ cfe/trunk/test/CodeGen/wchar-size.c Fri May 19 17:37:15 2017
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s -check-prefix=LONG-WCHAR
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -emit-llvm -o - %s | 
FileCheck %s -check-prefix=SHORT-WCHAR
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - 
-fshort-wchar %s | FileCheck %s -check-prefix=SHORT-WCHAR
+// Note: -fno-short-wchar implies the target default is used; so there is no
+// need to test this separately here.
+
+// LONG-WCHAR: !{{[0-9]+}} = !{i32 {{[0-9]+}}, !"wchar_size", i32 4}
+// SHORT-WCHAR: !{{[0-9]+}} = !{i32 {{[0-9]+}}, !"wchar_size", i32 2}


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


r303474 - Revert "CodeGenModule: Always output wchar_size, check LLVM assumptions."

2017-05-19 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri May 19 19:38:27 2017
New Revision: 303474

URL: http://llvm.org/viewvc/llvm-project?rev=303474&view=rev
Log:
Revert "CodeGenModule: Always output wchar_size, check LLVM assumptions."

Let's revert this for now (and with it the assert()) to get the bots
back to green until I have LLVM synced up properly.

This reverts commit r303463.

Removed:
cfe/trunk/test/CodeGen/wchar-size.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=303474&r1=303473&r2=303474&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri May 19 19:38:27 2017
@@ -45,7 +45,6 @@
 #include "clang/Frontend/CodeGenOptions.h"
 #include "clang/Sema/SemaDiagnostic.h"
 #include "llvm/ADT/Triple.h"
-#include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/CallSite.h"
 #include "llvm/IR/CallingConv.h"
 #include "llvm/IR/DataLayout.h"
@@ -466,24 +465,18 @@ void CodeGenModule::Release() {
 getModule().addModuleFlag(llvm::Module::Warning, "Debug Info Version",
   llvm::DEBUG_METADATA_VERSION);
 
-  // Width of wchar_t in bytes
-  uint64_t WCharWidth =
-  Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
-  assert(LangOpts.ShortWChar ||
- llvm::TargetLibraryInfoImpl::getTargetWCharSize(Target.getTriple()) ==
- Target.getWCharWidth() / 8 &&
- "LLVM wchar_t size out of sync");
-
   // We need to record the widths of enums and wchar_t, so that we can generate
-  // the correct build attributes in the ARM backend. wchar_size is also used 
by
-  // TargetLibraryInfo.
-  getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
-
+  // the correct build attributes in the ARM backend.
   llvm::Triple::ArchType Arch = Context.getTargetInfo().getTriple().getArch();
   if (   Arch == llvm::Triple::arm
   || Arch == llvm::Triple::armeb
   || Arch == llvm::Triple::thumb
   || Arch == llvm::Triple::thumbeb) {
+// Width of wchar_t in bytes
+uint64_t WCharWidth =
+Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
+getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
+
 // The minimum width of an enum in bytes
 uint64_t EnumWidth = Context.getLangOpts().ShortEnums ? 1 : 4;
 getModule().addModuleFlag(llvm::Module::Error, "min_enum_size", EnumWidth);

Removed: cfe/trunk/test/CodeGen/wchar-size.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/wchar-size.c?rev=303473&view=auto
==
--- cfe/trunk/test/CodeGen/wchar-size.c (original)
+++ cfe/trunk/test/CodeGen/wchar-size.c (removed)
@@ -1,8 +0,0 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s -check-prefix=LONG-WCHAR
-// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -emit-llvm -o - %s | 
FileCheck %s -check-prefix=SHORT-WCHAR
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - 
-fshort-wchar %s | FileCheck %s -check-prefix=SHORT-WCHAR
-// Note: -fno-short-wchar implies the target default is used; so there is no
-// need to test this separately here.
-
-// LONG-WCHAR: !{{[0-9]+}} = !{i32 {{[0-9]+}}, !"wchar_size", i32 4}
-// SHORT-WCHAR: !{{[0-9]+}} = !{i32 {{[0-9]+}}, !"wchar_size", i32 2}


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


r303478 - CodeGenModule: Always output wchar_size, check LLVM assumptions.

2017-05-19 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri May 19 20:29:55 2017
New Revision: 303478

URL: http://llvm.org/viewvc/llvm-project?rev=303478&view=rev
Log:
CodeGenModule: Always output wchar_size, check LLVM assumptions.

Re-commit r303463 now that LLVM is fixed and adjust some lit tests.

llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.

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

Added:
cfe/trunk/test/CodeGen/wchar-size.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGenCUDA/flush-denormals.cu
cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=303478&r1=303477&r2=303478&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri May 19 20:29:55 2017
@@ -45,6 +45,7 @@
 #include "clang/Frontend/CodeGenOptions.h"
 #include "clang/Sema/SemaDiagnostic.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/CallSite.h"
 #include "llvm/IR/CallingConv.h"
 #include "llvm/IR/DataLayout.h"
@@ -465,18 +466,24 @@ void CodeGenModule::Release() {
 getModule().addModuleFlag(llvm::Module::Warning, "Debug Info Version",
   llvm::DEBUG_METADATA_VERSION);
 
+  // Width of wchar_t in bytes
+  uint64_t WCharWidth =
+  Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
+  assert(LangOpts.ShortWChar ||
+ llvm::TargetLibraryInfoImpl::getTargetWCharSize(Target.getTriple()) ==
+ Target.getWCharWidth() / 8 &&
+ "LLVM wchar_t size out of sync");
+
   // We need to record the widths of enums and wchar_t, so that we can generate
-  // the correct build attributes in the ARM backend.
+  // the correct build attributes in the ARM backend. wchar_size is also used 
by
+  // TargetLibraryInfo.
+  getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
+
   llvm::Triple::ArchType Arch = Context.getTargetInfo().getTriple().getArch();
   if (   Arch == llvm::Triple::arm
   || Arch == llvm::Triple::armeb
   || Arch == llvm::Triple::thumb
   || Arch == llvm::Triple::thumbeb) {
-// Width of wchar_t in bytes
-uint64_t WCharWidth =
-Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
-getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
-
 // The minimum width of an enum in bytes
 uint64_t EnumWidth = Context.getLangOpts().ShortEnums ? 1 : 4;
 getModule().addModuleFlag(llvm::Module::Error, "min_enum_size", EnumWidth);

Added: cfe/trunk/test/CodeGen/wchar-size.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/wchar-size.c?rev=303478&view=auto
==
--- cfe/trunk/test/CodeGen/wchar-size.c (added)
+++ cfe/trunk/test/CodeGen/wchar-size.c Fri May 19 20:29:55 2017
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s -check-prefix=LONG-WCHAR
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -emit-llvm -o - %s | 
FileCheck %s -check-prefix=SHORT-WCHAR
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - 
-fshort-wchar %s | FileCheck %s -check-prefix=SHORT-WCHAR
+// Note: -fno-short-wchar implies the target default is used; so there is no
+// need to test this separately here.
+
+// LONG-WCHAR: !{{[0-9]+}} = !{i32 {{[0-9]+}}, !"wchar_size", i32 4}
+// SHORT-WCHAR: !{{[0-9]+}} = !{i32 {{[0-9]+}}, !"wchar_size", i32 2}

Modified: cfe/trunk/test/CodeGenCUDA/flush-denormals.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCUDA/flush-denormals.cu?rev=303478&r1=303477&r2=303478&view=diff
==
--- cfe/trunk/test/CodeGenCUDA/flush-denormals.cu (original)
+++ cfe/trunk/test/CodeGenCUDA/flush-denormals.cu Fri May 19 20:29:55 2017
@@ -18,8 +18,8 @@ extern "C" __device__ void foo() {}
 // FTZ: attributes #0 = {{.*}} "nvptx-f32ftz"="true"
 // NOFTZ-NOT: attributes #0 = {{.*}} "nvptx-f32ftz"
 
-// FTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// FTZ:!llvm.module.flags = !{{{.*}}[[MODFLAG:![0-9]+]]}
 // FTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 1}
 
-// NOFTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// NOFTZ:!llvm.module.flags = !{{{.*}}[[MODFLAG:![0-9]+]]}
 // NOFTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 0}

Modified: cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/t

[libcxx] r251529 - Adapt to lit change in llvm r251478-r251481

2015-10-28 Thread Matthias Braun via cfe-commits
Author: matze
Date: Wed Oct 28 12:20:33 2015
New Revision: 251529

URL: http://llvm.org/viewvc/llvm-project?rev=251529&view=rev
Log:
Adapt to lit change in llvm r251478-r251481

Sorry for the breakage.

Modified:
libcxx/trunk/test/libcxx/test/format.py

Modified: libcxx/trunk/test/libcxx/test/format.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/test/format.py?rev=251529&r1=251528&r2=251529&view=diff
==
--- libcxx/trunk/test/libcxx/test/format.py (original)
+++ libcxx/trunk/test/libcxx/test/format.py Wed Oct 28 12:20:33 2015
@@ -64,20 +64,24 @@ class LibcxxTestFormat(object):
 return (lit.Test.UNSUPPORTED,
 "A lit.local.cfg marked this unsupported")
 
-res = lit.TestRunner.parseIntegratedTestScript(
+script = lit.TestRunner.parseIntegratedTestScript(
 test, require_script=is_sh_test)
 # Check if a result for the test was returned. If so return that
 # result.
-if isinstance(res, lit.Test.Result):
-return res
+if isinstance(script, lit.Test.Result):
+return script
 if lit_config.noExecute:
 return lit.Test.Result(lit.Test.PASS)
-# res is not an instance of lit.test.Result. Expand res into its parts.
-script, tmpBase, execDir = res
+
 # Check that we don't have run lines on tests that don't support them.
 if not is_sh_test and len(script) != 0:
 lit_config.fatal('Unsupported RUN line found in test %s' % name)
 
+tmpDir, tmpBase = lit.TestRunner.getTempPaths(test)
+substitutions = lit.TestRunner.getDefaultSubstitutions(test, tmpDir,
+   tmpBase)
+script = lit.TestRunner.applySubstitutions(script, substitutions)
+
 # Dispatch the test based on its suffix.
 if is_sh_test:
 if not isinstance(self.executor, LocalExecutor):
@@ -86,11 +90,11 @@ class LibcxxTestFormat(object):
 return lit.Test.UNSUPPORTED, 'ShTest format not yet supported'
 return lit.TestRunner._runShTest(test, lit_config,
  self.execute_external, script,
- tmpBase, execDir)
+ tmpBase)
 elif is_fail_test:
 return self._evaluate_fail_test(test)
 elif is_pass_test:
-return self._evaluate_pass_test(test, tmpBase, execDir, lit_config)
+return self._evaluate_pass_test(test, tmpBase, lit_config)
 else:
 # No other test type is supported
 assert False
@@ -98,7 +102,8 @@ class LibcxxTestFormat(object):
 def _clean(self, exec_path):  # pylint: disable=no-self-use
 libcxx.util.cleanFile(exec_path)
 
-def _evaluate_pass_test(self, test, tmpBase, execDir, lit_config):
+def _evaluate_pass_test(self, test, tmpBase, lit_config):
+execDir = os.path.dirname(test.getExecPath())
 source_path = test.getSourcePath()
 exec_path = tmpBase + '.exe'
 object_path = tmpBase + '.o'


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


r276930 - test/Frontend: Add a test for aarch64 target CPU names.

2016-07-27 Thread Matthias Braun via cfe-commits
Author: matze
Date: Wed Jul 27 17:47:07 2016
New Revision: 276930

URL: http://llvm.org/viewvc/llvm-project?rev=276930&view=rev
Log:
test/Frontend: Add a test for aarch64 target CPU names.

Nothing else checked the target cpu names for aarch64 yet.
Add a test in the spirit of x86-target-cpu.c.

Added:
cfe/trunk/test/Frontend/aarch64-target-cpu.c

Added: cfe/trunk/test/Frontend/aarch64-target-cpu.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/aarch64-target-cpu.c?rev=276930&view=auto
==
--- cfe/trunk/test/Frontend/aarch64-target-cpu.c (added)
+++ cfe/trunk/test/Frontend/aarch64-target-cpu.c Wed Jul 27 17:47:07 2016
@@ -0,0 +1,14 @@
+// Ensure we support the various CPU names.
+//
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu cortex-a35 
-verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu cortex-a53 
-verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu cortex-a57 
-verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu cortex-a72 
-verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu cortex-a73 
-verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu cyclone -verify 
%s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu exynos-m1 
-verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu generic -verify 
%s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu kryo -verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -target-cpu vulcan -verify 
%s
+//
+// expected-no-diagnostics


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


r276931 - Basic/Targets.cpp: Reformat aarch64 CPU list.

2016-07-27 Thread Matthias Braun via cfe-commits
Author: matze
Date: Wed Jul 27 17:47:09 2016
New Revision: 276931

URL: http://llvm.org/viewvc/llvm-project?rev=276931&view=rev
Log:
Basic/Targets.cpp: Reformat aarch64 CPU list.

Having 1 entry per line and an alphabetical order is clearer and reduces
the risk of invalid merges.

Modified:
cfe/trunk/lib/Basic/Targets.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=276931&r1=276930&r2=276931&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed Jul 27 17:47:09 2016
@@ -5727,14 +5727,17 @@ public:
 
   bool setCPU(const std::string &Name) override {
 bool CPUKnown = llvm::StringSwitch(Name)
-.Case("generic", true)
-.Cases("cortex-a53", "cortex-a57", "cortex-a72",
-   "cortex-a35", "exynos-m1", true)
-.Case("cortex-a73", true)
-.Case("cyclone", true)
-.Case("kryo", true)
-.Case("vulcan", true)
-.Default(false);
+  .Case("cortex-a35", true)
+  .Case("cortex-a53", true)
+  .Case("cortex-a57", true)
+  .Case("cortex-a72", true)
+  .Case("cortex-a73", true)
+  .Case("cyclone", true)
+  .Case("exynos-m1", true)
+  .Case("generic", true)
+  .Case("kryo", true)
+  .Case("vulcan", true)
+  .Default(false);
 return CPUKnown;
   }
 


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


[libcxx] r278191 - test/hard_link_count(): Fix test on darwin

2016-08-09 Thread Matthias Braun via cfe-commits
Author: matze
Date: Tue Aug  9 20:02:28 2016
New Revision: 278191

URL: http://llvm.org/viewvc/llvm-project?rev=278191&view=rev
Log:
test/hard_link_count(): Fix test on darwin

The hard link count that stat reports are different between normal hfs and the
case sensitive variant. Accept both.

Modified:

libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp

Modified: 
libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp?rev=278191&r1=278190&r2=278191&view=diff
==
--- 
libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
 Tue Aug  9 20:02:28 2016
@@ -45,18 +45,27 @@ TEST_CASE(hard_link_count_for_file)
 
 TEST_CASE(hard_link_count_for_directory)
 {
-uintmax_t DirExpect = 3;
-uintmax_t Dir3Expect = 2;
+uintmax_t DirExpect = 3; // hard link from . .. and Dir2
+uintmax_t Dir3Expect = 2; // hard link from . ..
+uintmax_t DirExpectAlt = DirExpect;
+uintmax_t Dir3ExpectAlt = Dir3Expect;
 #if defined(__APPLE__)
-DirExpect += 2;
-Dir3Expect += 1;
+// Filesystems formatted with case sensitive hfs+ behave unixish as
+// expected. Normal hfs+ filesystems report the number of directory
+// entries instead.
+DirExpectAlt = 5; // .  ..  Dir2  file1  file2
+Dir3Expect = 3; // .  ..  file5
 #endif
-TEST_CHECK(hard_link_count(StaticEnv::Dir) == DirExpect);
-TEST_CHECK(hard_link_count(StaticEnv::Dir3) == Dir3Expect);
+TEST_CHECK(hard_link_count(StaticEnv::Dir) == DirExpect ||
+   hard_link_count(StaticEnv::Dir) == DirExpectAlt);
+TEST_CHECK(hard_link_count(StaticEnv::Dir3) == Dir3Expect ||
+   hard_link_count(StaticEnv::Dir3) == Dir3ExpectAlt);
 
 std::error_code ec;
-TEST_CHECK(hard_link_count(StaticEnv::Dir, ec) == DirExpect);
-TEST_CHECK(hard_link_count(StaticEnv::Dir3, ec) == Dir3Expect);
+TEST_CHECK(hard_link_count(StaticEnv::Dir, ec) == DirExpect ||
+   hard_link_count(StaticEnv::Dir, ec) == DirExpectAlt);
+TEST_CHECK(hard_link_count(StaticEnv::Dir3, ec) == Dir3Expect ||
+   hard_link_count(StaticEnv::Dir3, ec) == Dir3ExpectAlt);
 }
 TEST_CASE(hard_link_count_increments_test)
 {


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


[clang-tools-extra] r259424 - Fix build problem by lower SmallSet to a reasonable value

2016-02-01 Thread Matthias Braun via cfe-commits
Author: matze
Date: Mon Feb  1 16:18:58 2016
New Revision: 259424

URL: http://llvm.org/viewvc/llvm-project?rev=259424&view=rev
Log:
Fix build problem by lower SmallSet to a reasonable value

Modified:
clang-tools-extra/trunk/modularize/PreprocessorTracker.cpp

Modified: clang-tools-extra/trunk/modularize/PreprocessorTracker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/modularize/PreprocessorTracker.cpp?rev=259424&r1=259423&r2=259424&view=diff
==
--- clang-tools-extra/trunk/modularize/PreprocessorTracker.cpp (original)
+++ clang-tools-extra/trunk/modularize/PreprocessorTracker.cpp Mon Feb  1 
16:18:58 2016
@@ -1276,7 +1276,7 @@ private:
   std::vector HeaderStack;
   std::vector InclusionPaths;
   InclusionPathHandle CurrentInclusionPathHandle;
-  llvm::SmallSet HeadersInThisCompile;
+  llvm::SmallSet HeadersInThisCompile;
   std::vector IncludeDirectives;
   MacroExpansionMap MacroExpansions;
   ConditionalExpansionMap ConditionalExpansions;


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


Re: [PATCH] D18752: Documented standard substitutions defined by lit

2016-04-04 Thread Matthias Braun via cfe-commits
MatzeB added a comment.

Most patterns and several of the ones coming from lit.local.cfg are explained 
in TestingGuide.rst as well. On the other hand it makes sense to explain the 
lit specific substitutions in the lit docu, maybe just add an additional link 
to the TestingGuide.rst to reference this section for additional lit flags?


http://reviews.llvm.org/D18752



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


Re: [PATCH] D18752: Documented standard substitutions defined by lit

2016-04-04 Thread Matthias Braun via cfe-commits
MatzeB accepted this revision.
MatzeB added a comment.
This revision is now accepted and ready to land.

I'd probably go for a term like "pattern" instead of macro (there is no 
parameters or anything more complicated). The explanation for %t/%T is not 
helpful in the current form. Maybe something like 'temporary file name unique 
to the test'/'temporary directory unique to the test'.

Apart from that LGTM.


http://reviews.llvm.org/D18752



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


[PATCH] D21338: cc1_main: Do not print statistics in -disable_free mode.

2016-06-14 Thread Matthias Braun via cfe-commits
MatzeB created this revision.
MatzeB added reviewers: doug.gregor, bkramer.
MatzeB added a subscriber: cfe-commits.
MatzeB set the repository for this revision to rL LLVM.
Herald added a subscriber: mcrosier.

llvm statistics are currently printed when the destructor of a
"static ManagedStatic StatInfo" in llvm runs.
This destructor currently runs in each case as part of llvm_shutdown()
which is run even in disable_free mode as part of main(). I assume that
this hasn't always been the case.

Removing the special code here avoids the statistics getting printed
twice.

Repository:
  rL LLVM

http://reviews.llvm.org/D21338

Files:
  tools/driver/cc1_main.cpp

Index: tools/driver/cc1_main.cpp
===
--- tools/driver/cc1_main.cpp
+++ tools/driver/cc1_main.cpp
@@ -126,8 +126,6 @@
 
   // When running with -disable-free, don't do any destruction or shutdown.
   if (Clang->getFrontendOpts().DisableFree) {
-if (llvm::AreStatisticsEnabled() || Clang->getFrontendOpts().ShowStats)
-  llvm::PrintStatistics();
 BuryPointer(std::move(Clang));
 return !Success;
   }


Index: tools/driver/cc1_main.cpp
===
--- tools/driver/cc1_main.cpp
+++ tools/driver/cc1_main.cpp
@@ -126,8 +126,6 @@
 
   // When running with -disable-free, don't do any destruction or shutdown.
   if (Clang->getFrontendOpts().DisableFree) {
-if (llvm::AreStatisticsEnabled() || Clang->getFrontendOpts().ShowStats)
-  llvm::PrintStatistics();
 BuryPointer(std::move(Clang));
 return !Success;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r272820 - cc1_main: Do not print statistics twice in -disable_free mode.

2016-06-15 Thread Matthias Braun via cfe-commits
Author: matze
Date: Wed Jun 15 14:24:55 2016
New Revision: 272820

URL: http://llvm.org/viewvc/llvm-project?rev=272820&view=rev
Log:
cc1_main: Do not print statistics twice in -disable_free mode.

llvm statistics are currently printed when the destructor of a "static
ManagedStatic StatInfo" in llvm runs.  This destructor
currently runs in each case as part of llvm_shutdown() which is run even
in disable_free mode as part of main(). I assume that this hasn't always
been the case.

Removing the special code here avoids the statistics getting printed
twice.

Differential Revision: http://reviews.llvm.org/D21338

Modified:
cfe/trunk/tools/driver/cc1_main.cpp

Modified: cfe/trunk/tools/driver/cc1_main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1_main.cpp?rev=272820&r1=272819&r2=272820&view=diff
==
--- cfe/trunk/tools/driver/cc1_main.cpp (original)
+++ cfe/trunk/tools/driver/cc1_main.cpp Wed Jun 15 14:24:55 2016
@@ -126,8 +126,6 @@ int cc1_main(ArrayRef Argv
 
   // When running with -disable-free, don't do any destruction or shutdown.
   if (Clang->getFrontendOpts().DisableFree) {
-if (llvm::AreStatisticsEnabled() || Clang->getFrontendOpts().ShowStats)
-  llvm::PrintStatistics();
 BuryPointer(std::move(Clang));
 return !Success;
   }


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


Re: [PATCH] D16115: [test-suite] Add ClangAnalyzerBenchmarks directory to test-suite repository

2016-01-12 Thread Matthias Braun via cfe-commits
MatzeB added a comment.

Putting static-analyzer tests into the test-suite sounds good to me, the static 
analyzer is part of llvm so this should be fine. Though I'd like to wait a bit 
to hear other opinions on this matter.

As for the patch itself:

- I'd call the directory ClangAnalyzer
- For the external file you should provide a sha256 (or md5) sum and ideally 
check it in the download script, so other people can be sure that the reference 
results do indeed match the artifact being analyzed.
- Why is there a subdirectory "2016-01-11-134007-41609-1" in the 
RefScanBuildResults directory, that name appears arbitrary for reference 
results.


http://reviews.llvm.org/D16115



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


Re: [PATCH] D16115: [test-suite] Add ClangAnalyzerBenchmarks directory to test-suite repository

2016-01-12 Thread Matthias Braun via cfe-commits
MatzeB accepted this revision.
MatzeB added a comment.
This revision is now accepted and ready to land.

LGTM, though you should wait a week or two for other opinions before committing.


http://reviews.llvm.org/D16115



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


[PATCH] D16705: Avoid overly large SmallPtrSet/SmallSet

2016-01-28 Thread Matthias Braun via cfe-commits
MatzeB created this revision.
MatzeB added reviewers: chandlerc, reames, echristo.
MatzeB added a subscriber: cfe-commits.
MatzeB set the repository for this revision to rL LLVM.
Herald added a subscriber: mcrosier.

These sets perform linear searching in small mode so it is never a good
idea to use SmallSize/N bigger than 32.

Repository:
  rL LLVM

http://reviews.llvm.org/D16705

Files:
  lib/Analysis/PseudoConstantAnalysis.cpp
  lib/Sema/SemaDeclObjC.cpp
  lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
  lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp

Index: lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp
+++ lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp
@@ -26,10 +26,6 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
 #include "llvm/ADT/SmallSet.h"
 
-// The number of CFGBlock pointers we want to reserve memory for. This is used
-// once for each function we analyze.
-#define DEFAULT_CFGBLOCKS 256
-
 using namespace clang;
 using namespace ento;
 
@@ -39,7 +35,7 @@
   void checkEndAnalysis(ExplodedGraph &G, BugReporter &B,
 ExprEngine &Eng) const;
 private:
-  typedef llvm::SmallSet CFGBlocksSet;
+  typedef llvm::SmallSet CFGBlocksSet;
 
   static inline const Stmt *getUnreachableStmt(const CFGBlock *CB);
   static void FindUnreachableEntryPoints(const CFGBlock *CB,
Index: lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
+++ lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
@@ -43,7 +43,7 @@
 ExprEngine &Eng) const {
   const CFG *C = nullptr;
   const SourceManager &SM = B.getSourceManager();
-  llvm::SmallPtrSet reachable;
+  llvm::SmallPtrSet reachable;
 
   // Root node should have the location context of the top most function.
   const ExplodedNode *GraphRoot = *G.roots_begin();
Index: lib/Sema/SemaDeclObjC.cpp
===
--- lib/Sema/SemaDeclObjC.cpp
+++ lib/Sema/SemaDeclObjC.cpp
@@ -3843,7 +3843,7 @@
 }
   }
 
-  typedef llvm::SmallPtrSet::iterator iterator;
+  typedef llvm::SmallPtrSetImpl::iterator iterator;
   iterator begin() const { return Overridden.begin(); }
   iterator end() const { return Overridden.end(); }
 
Index: lib/Analysis/PseudoConstantAnalysis.cpp
===
--- lib/Analysis/PseudoConstantAnalysis.cpp
+++ lib/Analysis/PseudoConstantAnalysis.cpp
@@ -22,9 +22,7 @@
 
 using namespace clang;
 
-// The number of ValueDecls we want to keep track of by default (per-function)
-#define VARDECL_SET_SIZE 256
-typedef llvm::SmallPtrSet VarDeclSet;
+typedef llvm::SmallPtrSet VarDeclSet;
 
 PseudoConstantAnalysis::PseudoConstantAnalysis(const Stmt *DeclBody) :
   DeclBody(DeclBody), Analyzed(false) {


Index: lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp
+++ lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp
@@ -26,10 +26,6 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
 #include "llvm/ADT/SmallSet.h"
 
-// The number of CFGBlock pointers we want to reserve memory for. This is used
-// once for each function we analyze.
-#define DEFAULT_CFGBLOCKS 256
-
 using namespace clang;
 using namespace ento;
 
@@ -39,7 +35,7 @@
   void checkEndAnalysis(ExplodedGraph &G, BugReporter &B,
 ExprEngine &Eng) const;
 private:
-  typedef llvm::SmallSet CFGBlocksSet;
+  typedef llvm::SmallSet CFGBlocksSet;
 
   static inline const Stmt *getUnreachableStmt(const CFGBlock *CB);
   static void FindUnreachableEntryPoints(const CFGBlock *CB,
Index: lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
+++ lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
@@ -43,7 +43,7 @@
 ExprEngine &Eng) const {
   const CFG *C = nullptr;
   const SourceManager &SM = B.getSourceManager();
-  llvm::SmallPtrSet reachable;
+  llvm::SmallPtrSet reachable;
 
   // Root node should have the location context of the top most function.
   const ExplodedNode *GraphRoot = *G.roots_begin();
Index: lib/Sema/SemaDeclObjC.cpp
===
--- lib/Sema/SemaDeclObjC.cpp
+++ lib/Sema/SemaDeclObjC.cpp
@@ -3843,7 +3843,7 @@
 }
   }
 
-  typedef llvm::SmallPtrSet::iterator iterator;
+  typedef llvm::SmallPtrSetImpl::iterator iterator;
   iterator begin() const { return Overridden.begin(); }
   iterator end() const { return Overridden.end(); }
 
Index: lib/Analysi

r259284 - Avoid overly large SmallPtrSet/SmallSet

2016-01-29 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Jan 29 19:27:06 2016
New Revision: 259284

URL: http://llvm.org/viewvc/llvm-project?rev=259284&view=rev
Log:
Avoid overly large SmallPtrSet/SmallSet

These sets perform linear searching in small mode so it is never a good
idea to use SmallSize/N bigger than 32.

Differential Revision: http://reviews.llvm.org/D16705

Modified:
cfe/trunk/lib/Analysis/PseudoConstantAnalysis.cpp
cfe/trunk/lib/Sema/SemaDeclObjC.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp

Modified: cfe/trunk/lib/Analysis/PseudoConstantAnalysis.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/PseudoConstantAnalysis.cpp?rev=259284&r1=259283&r2=259284&view=diff
==
--- cfe/trunk/lib/Analysis/PseudoConstantAnalysis.cpp (original)
+++ cfe/trunk/lib/Analysis/PseudoConstantAnalysis.cpp Fri Jan 29 19:27:06 2016
@@ -22,9 +22,7 @@
 
 using namespace clang;
 
-// The number of ValueDecls we want to keep track of by default (per-function)
-#define VARDECL_SET_SIZE 256
-typedef llvm::SmallPtrSet VarDeclSet;
+typedef llvm::SmallPtrSet VarDeclSet;
 
 PseudoConstantAnalysis::PseudoConstantAnalysis(const Stmt *DeclBody) :
   DeclBody(DeclBody), Analyzed(false) {

Modified: cfe/trunk/lib/Sema/SemaDeclObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclObjC.cpp?rev=259284&r1=259283&r2=259284&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclObjC.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclObjC.cpp Fri Jan 29 19:27:06 2016
@@ -3843,7 +3843,7 @@ public:
 }
   }
 
-  typedef llvm::SmallPtrSet::iterator iterator;
+  typedef llvm::SmallPtrSetImpl::iterator iterator;
   iterator begin() const { return Overridden.begin(); }
   iterator end() const { return Overridden.end(); }
 

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp?rev=259284&r1=259283&r2=259284&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/AnalyzerStatsChecker.cpp Fri Jan 29 
19:27:06 2016
@@ -43,7 +43,7 @@ void AnalyzerStatsChecker::checkEndAnaly
 ExprEngine &Eng) const {
   const CFG *C = nullptr;
   const SourceManager &SM = B.getSourceManager();
-  llvm::SmallPtrSet reachable;
+  llvm::SmallPtrSet reachable;
 
   // Root node should have the location context of the top most function.
   const ExplodedNode *GraphRoot = *G.roots_begin();

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp?rev=259284&r1=259283&r2=259284&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp Fri Jan 29 
19:27:06 2016
@@ -26,10 +26,6 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
 #include "llvm/ADT/SmallSet.h"
 
-// The number of CFGBlock pointers we want to reserve memory for. This is used
-// once for each function we analyze.
-#define DEFAULT_CFGBLOCKS 256
-
 using namespace clang;
 using namespace ento;
 
@@ -39,7 +35,7 @@ public:
   void checkEndAnalysis(ExplodedGraph &G, BugReporter &B,
 ExprEngine &Eng) const;
 private:
-  typedef llvm::SmallSet CFGBlocksSet;
+  typedef llvm::SmallSet CFGBlocksSet;
 
   static inline const Stmt *getUnreachableStmt(const CFGBlock *CB);
   static void FindUnreachableEntryPoints(const CFGBlock *CB,


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


r253741 - Fix testcase when building on darwin

2015-11-20 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Nov 20 18:56:41 2015
New Revision: 253741

URL: http://llvm.org/viewvc/llvm-project?rev=253741&view=rev
Log:
Fix testcase when building on darwin

Explicitely specify a target to avoid "_" prefixes on the names.

Modified:
cfe/trunk/test/CodeGen/c-unicode.c

Modified: cfe/trunk/test/CodeGen/c-unicode.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/c-unicode.c?rev=253741&r1=253740&r2=253741&view=diff
==
--- cfe/trunk/test/CodeGen/c-unicode.c (original)
+++ cfe/trunk/test/CodeGen/c-unicode.c Fri Nov 20 18:56:41 2015
@@ -1,5 +1,5 @@
-// RUN: %clang -S %s -o - | FileCheck %s -check-prefix=ALLOWED
-// RUN: not %clang -std=c89 -S %s -o - 2>&1 | FileCheck %s -check-prefix=DENIED
+// RUN: %clang --target=x86_64--linux-gnu -S %s -o - | FileCheck %s 
-check-prefix=ALLOWED
+// RUN: not %clang --target=x86_64--linux-gnu -std=c89 -S %s -o - 2>&1 | 
FileCheck %s -check-prefix=DENIED
 int \uaccess = 0;
 // ALLOWED: "곎ss":
 // ALLOWED-NOT: "\uaccess":


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


r253758 - Fix c-unicode.c testcase again.

2015-11-20 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Nov 20 20:13:29 2015
New Revision: 253758

URL: http://llvm.org/viewvc/llvm-project?rev=253758&view=rev
Log:
Fix c-unicode.c testcase again.

Specifying a fixed triple is not possible because that target may not
even be compiler. Go for a simpler fix by using a _? regex for the
prefix.

Modified:
cfe/trunk/test/CodeGen/c-unicode.c

Modified: cfe/trunk/test/CodeGen/c-unicode.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/c-unicode.c?rev=253758&r1=253757&r2=253758&view=diff
==
--- cfe/trunk/test/CodeGen/c-unicode.c (original)
+++ cfe/trunk/test/CodeGen/c-unicode.c Fri Nov 20 20:13:29 2015
@@ -1,7 +1,7 @@
-// RUN: %clang --target=x86_64--linux-gnu -S %s -o - | FileCheck %s 
-check-prefix=ALLOWED
-// RUN: not %clang --target=x86_64--linux-gnu -std=c89 -S %s -o - 2>&1 | 
FileCheck %s -check-prefix=DENIED
+// RUN: %clang -S %s -o - | FileCheck %s -check-prefix=ALLOWED
+// RUN: not %clang -std=c89 -S %s -o - 2>&1 | FileCheck %s -check-prefix=DENIED
 int \uaccess = 0;
-// ALLOWED: "곎ss":
+// ALLOWED: "{{_?}}곎ss":
 // ALLOWED-NOT: "\uaccess":
 // DENIED: warning: universal character names are only valid in C99 or C++; 
treating as '\' followed by identifier [-Wunicode]
 // DENIED: error: expected identifier or '('


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


r253760 - Let's try to fix this test again with a fixed target triple

2015-11-20 Thread Matthias Braun via cfe-commits
Author: matze
Date: Fri Nov 20 20:28:42 2015
New Revision: 253760

URL: http://llvm.org/viewvc/llvm-project?rev=253760&view=rev
Log:
Let's try to fix this test again with a fixed target triple

Modified:
cfe/trunk/test/CodeGen/c-unicode.c

Modified: cfe/trunk/test/CodeGen/c-unicode.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/c-unicode.c?rev=253760&r1=253759&r2=253760&view=diff
==
--- cfe/trunk/test/CodeGen/c-unicode.c (original)
+++ cfe/trunk/test/CodeGen/c-unicode.c Fri Nov 20 20:28:42 2015
@@ -1,7 +1,8 @@
-// RUN: %clang -S %s -o - | FileCheck %s -check-prefix=ALLOWED
-// RUN: not %clang -std=c89 -S %s -o - 2>&1 | FileCheck %s -check-prefix=DENIED
+// REQUIRES: x86-registered-target
+// RUN: %clang --target=x86_64--linug-gnu -S %s -o - | FileCheck %s 
-check-prefix=ALLOWED
+// RUN: not %clang --target=x86_64--linux-gnu -std=c89 -S %s -o - 2>&1 | 
FileCheck %s -check-prefix=DENIED
 int \uaccess = 0;
-// ALLOWED: "{{_?}}곎ss":
+// ALLOWED: "곎ss":
 // ALLOWED-NOT: "\uaccess":
 // DENIED: warning: universal character names are only valid in C99 or C++; 
treating as '\' followed by identifier [-Wunicode]
 // DENIED: error: expected identifier or '('


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


[clang-tools-extra] r254477 - Force test to a target that supports thread_local

2015-12-01 Thread Matthias Braun via cfe-commits
Author: matze
Date: Tue Dec  1 19:12:06 2015
New Revision: 254477

URL: http://llvm.org/viewvc/llvm-project?rev=254477&view=rev
Log:
Force test to a target that supports thread_local

This should fix darwin bots.

Modified:
clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp

Modified: 
clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp?rev=254477&r1=254476&r2=254477&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp 
Tue Dec  1 19:12:06 2015
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s cert-err58-cpp %t
+// RUN: %check_clang_tidy %s cert-err58-cpp %t -- -- -std=c++11 -target 
x86_64-pc-linux-gnu
 
 struct S {
   S() noexcept(false);


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


[clang-tools-extra] [llvm] Full path names are used in several unittests instead of the binary name. Fix up the testcase failures (PR #107974)

2024-09-10 Thread Matthias Braun via cfe-commits

MatzeB wrote:

Please provide additional context in your summary on how this happens.

My understanding is that this is for a setup with linux binfmt-misc + qemu 
running aarch64 binaries on an x86 system. The fact that we end up with 
absolute pathnames in `argv[0]` may be a bug in qemu or binfmt-misc or maybe 
it's not specified in posix etc. and any behavior is allowed (I don't really 
know).

Given this only affects 4 tests in all of `llvm-project` I think it is fine to 
just adapt the tests (even if it would turn out incorrect behavior).

So LGTM but maybe wait a couple days in case there are different opinions.

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


[clang-tools-extra] [llvm] Full path names are used in several unittests instead of the binary name. Fix up the testcase failures (PR #107974)

2024-09-10 Thread Matthias Braun via cfe-commits

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


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


[clang] Use cmake to find perl executable (PR #91275)

2024-05-06 Thread Matthias Braun via cfe-commits

https://github.com/MatzeB created 
https://github.com/llvm/llvm-project/pull/91275

None

>From c0b7ec2e336476b1a1d6cf05d07bfde2f3dc88a4 Mon Sep 17 00:00:00 2001
From: Matthias Braun 
Date: Mon, 6 May 2024 14:39:37 -0700
Subject: [PATCH] Use cmake to find perl executable

---
 clang/CMakeLists.txt   | 2 ++
 clang/test/Analysis/scan-build/cxx-name.test   | 2 +-
 clang/test/Analysis/scan-build/deduplication.test  | 3 +--
 clang/test/Analysis/scan-build/exclude_directories.test| 3 +--
 clang/test/Analysis/scan-build/help.test   | 3 +--
 clang/test/Analysis/scan-build/html_output.test| 3 +--
 clang/test/Analysis/scan-build/lit.local.cfg   | 3 ++-
 clang/test/Analysis/scan-build/plist_html_output.test  | 3 +--
 clang/test/Analysis/scan-build/plist_output.test   | 3 +--
 .../test/Analysis/scan-build/rebuild_index/rebuild_index.test  | 3 +--
 clang/test/Analysis/scan-build/silence-core-checkers.test  | 3 +--
 clang/test/lit.cfg.py  | 3 +++
 clang/test/lit.site.cfg.py.in  | 1 +
 13 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index cf97e3c6e851ae..c20ce47a12abbd 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -523,6 +523,8 @@ endif()
 
 
 if( CLANG_INCLUDE_TESTS )
+  find_package(Perl)
+
   add_subdirectory(unittests)
   list(APPEND CLANG_TEST_DEPS ClangUnitTests)
   list(APPEND CLANG_TEST_PARAMS
diff --git a/clang/test/Analysis/scan-build/cxx-name.test 
b/clang/test/Analysis/scan-build/cxx-name.test
index 483762d619d178..789f7e0ac197c6 100644
--- a/clang/test/Analysis/scan-build/cxx-name.test
+++ b/clang/test/Analysis/scan-build/cxx-name.test
@@ -1,4 +1,4 @@
-REQUIRES: shell
+REQUIRES: perl
 
 RUN: %scan-build sh -c 'echo "CLANG_CXX=/$(basename "$CLANG_CXX")/"' | 
FileCheck %s
 
diff --git a/clang/test/Analysis/scan-build/deduplication.test 
b/clang/test/Analysis/scan-build/deduplication.test
index 56d888e5fc12a2..62375d9aadfa85 100644
--- a/clang/test/Analysis/scan-build/deduplication.test
+++ b/clang/test/Analysis/scan-build/deduplication.test
@@ -1,5 +1,4 @@
-// FIXME: Actually, "perl".
-REQUIRES: shell
+REQUIRES: perl
 
 RUN: rm -rf %t.output_dir && mkdir %t.output_dir
 RUN: %scan-build -o %t.output_dir \
diff --git a/clang/test/Analysis/scan-build/exclude_directories.test 
b/clang/test/Analysis/scan-build/exclude_directories.test
index c161e51b6d26c5..c15568f0b6bb9e 100644
--- a/clang/test/Analysis/scan-build/exclude_directories.test
+++ b/clang/test/Analysis/scan-build/exclude_directories.test
@@ -1,5 +1,4 @@
-// FIXME: Actually, "perl".
-REQUIRES: shell
+REQUIRES: perl
 
 RUN: rm -rf %t.output_dir && mkdir %t.output_dir
 RUN: %scan-build -o %t.output_dir %clang -S \
diff --git a/clang/test/Analysis/scan-build/help.test 
b/clang/test/Analysis/scan-build/help.test
index 61915d32609439..2966507b6080cd 100644
--- a/clang/test/Analysis/scan-build/help.test
+++ b/clang/test/Analysis/scan-build/help.test
@@ -1,5 +1,4 @@
-// FIXME: Actually, "perl".
-REQUIRES: shell
+REQUIRES: perl
 
 RUN: %scan-build -h | FileCheck %s
 RUN: %scan-build --help | FileCheck %s
diff --git a/clang/test/Analysis/scan-build/html_output.test 
b/clang/test/Analysis/scan-build/html_output.test
index add35d83b95887..2d5c001e83960d 100644
--- a/clang/test/Analysis/scan-build/html_output.test
+++ b/clang/test/Analysis/scan-build/html_output.test
@@ -1,5 +1,4 @@
-// FIXME: Actually, "perl".
-REQUIRES: shell
+REQUIRES: perl
 
 RUN: rm -rf %t.output_dir && mkdir %t.output_dir
 RUN: %scan-build -o %t.output_dir %clang -S 
%S/Inputs/single_null_dereference.c \
diff --git a/clang/test/Analysis/scan-build/lit.local.cfg 
b/clang/test/Analysis/scan-build/lit.local.cfg
index fab52b1c7bd679..e606243ea73a48 100644
--- a/clang/test/Analysis/scan-build/lit.local.cfg
+++ b/clang/test/Analysis/scan-build/lit.local.cfg
@@ -12,8 +12,9 @@ clang_path = config.clang if config.have_llvm_driver else 
os.path.realpath(confi
 config.substitutions.append(
 (
 "%scan-build",
-"'%s' --use-analyzer=%s "
+"'%s' '%s' --use-analyzer=%s "
 % (
+config.perl_executable,
 lit.util.which(
 "scan-build",
 os.path.join(config.clang_src_dir, "tools", "scan-build", 
"bin"),
diff --git a/clang/test/Analysis/scan-build/plist_html_output.test 
b/clang/test/Analysis/scan-build/plist_html_output.test
index c07891e35fbf33..811bca22b07643 100644
--- a/clang/test/Analysis/scan-build/plist_html_output.test
+++ b/clang/test/Analysis/scan-build/plist_html_output.test
@@ -1,5 +1,4 @@
-// FIXME: Actually, "perl".
-REQUIRES: shell
+REQUIRES: perl
 
 RUN: rm -rf %t.output_dir && mkdir %t.output_dir
 RUN: %scan-build -plist-html -o %t.output_dir %clang -S 
%S/Inputs/single_null_dereference.c \
diff --git a/clan

  1   2   >