[PATCH] D57838: [clang-cl] support /Oy- on aarch64

[Nathan Froyd via Phabricator via cfe-commits]

froydnj created this revision.
froydnj added a reviewer: mstorsjo.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.
Herald added a project: clang.

MSVC supports /Oy- on aarch64, so clang-cl should too.


Repository:
  rC Clang

https://reviews.llvm.org/D57838

Files:
  lib/Driver/ToolChains/MSVC.cpp
  test/Driver/cl-options.c


Index: test/Driver/cl-options.c
===
--- test/Driver/cl-options.c
+++ test/Driver/cl-options.c
@@ -178,6 +178,10 @@
 // Oy_2: -momit-leaf-frame-pointer
 // Oy_2: -O2
 
+// RUN: %clang_cl --target=aarch64-pc-windows-msvc -Werror /Oy- /O2 -### -- %s 
2>&1 | FileCheck -check-prefix=Oy_aarch64 %s
+// Oy_aarch64: -mdisable-fp-elim
+// Oy_aarch64: -O2
+
 // RUN: %clang_cl --target=i686-pc-win32 -Werror /O2 /O2 -### -- %s 2>&1 | 
FileCheck -check-prefix=O2O2 %s
 // O2O2: "-O2"
 
Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -1407,10 +1407,10 @@
   DAL.AddFlagArg(
   A, Opts.getOption(options::OPT_fno_omit_frame_pointer));
   } else {
-// Don't warn about /Oy- in 64-bit builds (where
+// Don't warn about /Oy- in x86-64 builds (where
 // SupportsForcingFramePointer is false).  The flag having no effect
 // there is a compiler-internal optimization, and people shouldn't have
-// to special-case their build files for 64-bit clang-cl.
+// to special-case their build files for x86-64 clang-cl.
 A->claim();
   }
   break;
@@ -1441,8 +1441,8 @@
   DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
   const OptTable &Opts = getDriver().getOpts();
 
-  // /Oy and /Oy- only has an effect under X86-32.
-  bool SupportsForcingFramePointer = getArch() == llvm::Triple::x86;
+  // /Oy and /Oy- don't have an effect on X86-64
+  bool SupportsForcingFramePointer = getArch() != llvm::Triple::x86_64;
 
   // The -O[12xd] flag actually expands to several flags.  We must desugar the
   // flags so that options embedded can be negated.  For example, the '-O2' 
flag


Index: test/Driver/cl-options.c
===
--- test/Driver/cl-options.c
+++ test/Driver/cl-options.c
@@ -178,6 +178,10 @@
 // Oy_2: -momit-leaf-frame-pointer
 // Oy_2: -O2
 
+// RUN: %clang_cl --target=aarch64-pc-windows-msvc -Werror /Oy- /O2 -### -- %s 2>&1 | FileCheck -check-prefix=Oy_aarch64 %s
+// Oy_aarch64: -mdisable-fp-elim
+// Oy_aarch64: -O2
+
 // RUN: %clang_cl --target=i686-pc-win32 -Werror /O2 /O2 -### -- %s 2>&1 | FileCheck -check-prefix=O2O2 %s
 // O2O2: "-O2"
 
Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -1407,10 +1407,10 @@
   DAL.AddFlagArg(
   A, Opts.getOption(options::OPT_fno_omit_frame_pointer));
   } else {
-// Don't warn about /Oy- in 64-bit builds (where
+// Don't warn about /Oy- in x86-64 builds (where
 // SupportsForcingFramePointer is false).  The flag having no effect
 // there is a compiler-internal optimization, and people shouldn't have
-// to special-case their build files for 64-bit clang-cl.
+// to special-case their build files for x86-64 clang-cl.
 A->claim();
   }
   break;
@@ -1441,8 +1441,8 @@
   DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
   const OptTable &Opts = getDriver().getOpts();
 
-  // /Oy and /Oy- only has an effect under X86-32.
-  bool SupportsForcingFramePointer = getArch() == llvm::Triple::x86;
+  // /Oy and /Oy- don't have an effect on X86-64
+  bool SupportsForcingFramePointer = getArch() != llvm::Triple::x86_64;
 
   // The -O[12xd] flag actually expands to several flags.  We must desugar the
   // flags so that options embedded can be negated.  For example, the '-O2' flag
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57838: [clang-cl] support /Oy- on aarch64

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

Thanks for the review, @mstorsjo.  Would you please land this for me?  I don't 
have commit access.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57838/new/

https://reviews.llvm.org/D57838



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

[PATCH] D81865: use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865



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

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

In D81865#2176014 , @bkramer wrote:

> Nice, those relocations have annoyed me for years. I'm worried about whether 
> the way you're accessing StaticDiagInfoDescriptionStringTable might be 
> undefined behavior. I won't block this change on that though.


Is there somebody who should review that particular bit?  My understanding is 
that it is OK, but my understanding of the C++ standard is not necessarily 
complete, and I'd like to get a second opinion.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865



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

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

In D81865#2176589 , @dblaikie wrote:

> I believe this falls under the (using cppreference ( 
> https://en.cppreference.com/w/cpp/language/union ) , since it's a bit easier 
> to read) UB clause: " It's undefined behavior to read from the member of the 
> union that wasn't most recently written. Many compilers implement, as a 
> non-standard language extension, the ability to read inactive members of a 
> union."
>
> Last member written to was the "StringTable" member, but then it's read from 
> the "String" member, so that'd be UB. Commonly supported, but UB - not sure 
> if we have a general statement that we depend on this behavior in LLVM, even 
> though it's non-standard (but it's possible that we do make such an 
> assumption about the compiler that's building LLVM). It'd be nice to avoid 
> that, though - and not too difficult, I think - I /believe/ it's valid to 
> take a pointer to an object, cast it to char*, compute a pointer to some 
> specific member and then cast it back to the right type and access. But I 
> could be wrong there. @rsmith would be the person to give an authoritative 
> answer.

Thanks for the explanation.  Is the language of "writing" applicable here, 
given that this is a constant blob of storage?  (I suppose the compiler is 
permitted to designate a particular member as having been "written"?)

Would it be more palatable to write:

  struct StaticDiagInfoDescriptionStringTable {
// members as char[] for each diagnostic
  };
  
  const StaticDiagInfoDescriptionStringTable StaticDiagInfoDescriptions = {
// define all the members
  };
  
  ...
  
  struct StaticDiagInfoRec {
...
StringRef getDescription() const {
  size_t MyIndex = this - &StaticDiagInfo[0];
  uint32_t StringOffset = StaticDiagInfoDescriptionOffsets[MyIndex];
  // Defined as a pointer to the first member, and (presumably) there is no 
internal padding.
  const char *StringTable = reinterpret_cast(&StaticDiagInfoDescriptions);
  return StringRef(&StringTable[StringOffset], DescriptionLen);
  };

and then we don't have to care about how the host compiler interprets access to 
different members of unions?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865

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

[PATCH] D82388: move "basic" builtins to TableGen

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

FWIW, an in-progress tree for the proposed move for all the 
architecture-specific builtins is:

https://github.com/froydnj/llvm-project/tree/move-builtins-to-tablegen

I don't know if the ARM/NEON/SVE builtins will be easily movable.  It looks 
like they are separately generated from existing `.td` files; while you could 
generate `.td` files containing all the appropriate `Builtin` etc. definitions, 
you cannot have tablegen input depend on tablegen'd output in the general case 
due to:

https://github.com/llvm/llvm-project/blob/c83ec0a633583e5b12e0aeb70627eb35f7cd4847/llvm/cmake/modules/TableGen.cmake#L11-L35

in the non-Ninja case.  If you try, you get circular dependencies.  One could 
maybe hack around this by giving certain files different suffixes, but that 
feels gross.

I'm not sure how to address that issue.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82388/new/

https://reviews.llvm.org/D82388



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

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

Ping for an opinion on the recent discussion of how to move forward with this 
patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865

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

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

Ping for an opinion on the recent discussion of how to move forward with this 
patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865

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

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG31a3c5fb45b7: [clang] use string tables for static 
diagnostic descriptions (authored by froydnj).

Changed prior to commit:
  https://reviews.llvm.org/D81865?vs=288628&id=294063#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865

Files:
  clang/lib/Basic/DiagnosticIDs.cpp

Index: clang/lib/Basic/DiagnosticIDs.cpp
===
--- clang/lib/Basic/DiagnosticIDs.cpp
+++ clang/lib/Basic/DiagnosticIDs.cpp
@@ -26,6 +26,78 @@
 
 namespace {
 
+struct StaticDiagInfoRec;
+
+// Store the descriptions in a separate table to avoid pointers that need to
+// be relocated, and also decrease the amount of data needed on 64-bit
+// platforms. See "How To Write Shared Libraries" by Ulrich Drepper.
+struct StaticDiagInfoDescriptionStringTable {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, DEFERRABLE, CATEGORY)\
+  char ENUM##_desc[sizeof(DESC)];
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
+const StaticDiagInfoDescriptionStringTable StaticDiagInfoDescriptions = {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, DEFERRABLE, CATEGORY)\
+  DESC,
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
+extern const StaticDiagInfoRec StaticDiagInfo[];
+
+// Stored separately from StaticDiagInfoRec to pack better.  Otherwise,
+// StaticDiagInfoRec would have extra padding on 64-bit platforms.
+const uint32_t StaticDiagInfoDescriptionOffsets[] = {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, DEFERRABLE, CATEGORY)\
+  offsetof(StaticDiagInfoDescriptionStringTable, ENUM##_desc),
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
 // Diagnostic classes.
 enum {
   CLASS_NOTE   = 0x01,
@@ -48,14 +120,16 @@
   uint16_t OptionGroupIndex;
 
   uint16_t DescriptionLen;
-  const char *DescriptionStr;
 
   unsigned getOptionGroupIndex() const {
 return OptionGroupIndex;
   }
 
   StringRef getDescription() const {
-return StringRef(DescriptionStr, DescriptionLen);
+size_t MyIndex = this - &StaticDiagInfo[0];
+uint32_t StringOffset = StaticDiagInfoDescriptionOffsets[MyIndex];
+const char* Table = reinterpret_cast(&StaticDiagInfoDescriptions);
+return StringRef(&Table[StringOffset], DescriptionLen);
   }
 
   diag::Flavor getFlavor() const {
@@ -93,14 +167,21 @@
 #undef VALIDATE_DIAG_SIZE
 #undef STRINGIFY_NAME
 
-} // namespace anonymous
-
-static const StaticDiagInfoRec StaticDiagInfo[] = {
+const StaticDiagInfoRec StaticDiagInfo[] = {
 #define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
  SHOWINSYSHEADER, DEFERRABLE, CATEGORY)\
-  {diag::ENUM, DEFAULT_SEVERITY, CLASS,  DiagnosticIDs::SFINA

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj added a comment.

In D81865#2293146 , @MaskRay wrote:

> In D81865#2293066 , @dblaikie wrote:
>
>> In D81865#2293059 , @MaskRay wrote:
>>
>>> @froydnj The committed version rG31a3c5fb45b78bdaa78d94ffcc9258e839002016 
>>>  
>>> appears to be very different from the review. I guess next time your 
>>> probably can upload the diff again if it is very diffierent
>>
>> Judging by a cursory glance at Phab's view of the delta ( 
>> https://reviews.llvm.org/rG4b64ce7428b66cacfe74dbd9dbc29aff6dfb84af ) it 
>> /looks/ like it wasn't too different. Mostly picking up upstream changes 
>> that added "DEFERRABLE"? (I think Phab uses light green for "this changed, 
>> but only because of upstream changes" and dark green is the actual patch 
>> changes?)
>
> Sorry for the noise. What I saw previously was a mere difference in the DIAG 
> macro and the new isDeferable... Maybe Phab presented the diff between two 
> Diffs to me. The updated view seems good.

I assumed that "add another parameter to a macro due to rebasing" was not a 
significant enough change to warrant reposting...but as this is the first patch 
I was committing myself, I probably should have been a bit more explicit in 
what I was committing (even re-asking for review?  I'm not sure of the norms 
around rebasing in the LLVM project).  My mistake!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865

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

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj updated this revision to Diff 288628.
froydnj added a comment.

Updated to use a struct instead of a union for the actual table in an effort to 
avoid UB.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865

Files:
  clang/lib/Basic/DiagnosticIDs.cpp

Index: clang/lib/Basic/DiagnosticIDs.cpp
===
--- clang/lib/Basic/DiagnosticIDs.cpp
+++ clang/lib/Basic/DiagnosticIDs.cpp
@@ -26,6 +26,78 @@
 
 namespace {
 
+struct StaticDiagInfoRec;
+
+// Store the descriptions in a separate table to avoid pointers that need to
+// be relocated, and also decrease the amount of data needed on 64-bit
+// platforms. See "How To Write Shared Libraries" by Ulrich Drepper.
+struct StaticDiagInfoDescriptionStringTable {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, CATEGORY)\
+  char ENUM##_desc[sizeof(DESC)];
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
+const StaticDiagInfoDescriptionStringTable StaticDiagInfoDescriptions = {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, CATEGORY)\
+  DESC,
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
+extern const StaticDiagInfoRec StaticDiagInfo[];
+
+// Stored separately from StaticDiagInfoRec to pack better.  Otherwise,
+// StaticDiagInfoRec would have extra padding on 64-bit platforms.
+const uint32_t StaticDiagInfoDescriptionOffsets[] = {
+#define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
+ SHOWINSYSHEADER, CATEGORY)\
+  offsetof(StaticDiagInfoDescriptionStringTable, ENUM##_desc),
+  // clang-format off
+#include "clang/Basic/DiagnosticCommonKinds.inc"
+#include "clang/Basic/DiagnosticDriverKinds.inc"
+#include "clang/Basic/DiagnosticFrontendKinds.inc"
+#include "clang/Basic/DiagnosticSerializationKinds.inc"
+#include "clang/Basic/DiagnosticLexKinds.inc"
+#include "clang/Basic/DiagnosticParseKinds.inc"
+#include "clang/Basic/DiagnosticASTKinds.inc"
+#include "clang/Basic/DiagnosticCommentKinds.inc"
+#include "clang/Basic/DiagnosticCrossTUKinds.inc"
+#include "clang/Basic/DiagnosticSemaKinds.inc"
+#include "clang/Basic/DiagnosticAnalysisKinds.inc"
+#include "clang/Basic/DiagnosticRefactoringKinds.inc"
+  // clang-format on
+#undef DIAG
+};
+
 // Diagnostic classes.
 enum {
   CLASS_NOTE   = 0x01,
@@ -47,14 +119,16 @@
   uint16_t OptionGroupIndex;
 
   uint16_t DescriptionLen;
-  const char *DescriptionStr;
 
   unsigned getOptionGroupIndex() const {
 return OptionGroupIndex;
   }
 
   StringRef getDescription() const {
-return StringRef(DescriptionStr, DescriptionLen);
+size_t MyIndex = this - &StaticDiagInfo[0];
+uint32_t StringOffset = StaticDiagInfoDescriptionOffsets[MyIndex];
+const char* Table = reinterpret_cast(&StaticDiagInfoDescriptions);
+return StringRef(&Table[StringOffset], DescriptionLen);
   }
 
   diag::Flavor getFlavor() const {
@@ -91,16 +165,20 @@
 #undef VALIDATE_DIAG_SIZE
 #undef STRINGIFY_NAME
 
-} // namespace anonymous
-
-static const StaticDiagInfoRec StaticDiagInfo[] = {
+const StaticDiagInfoRec StaticDiagInfo[] = {
 #define DIAG(ENUM, CLASS, DEFAULT_SEVERITY, DESC, GROUP, SFINAE, NOWERROR, \
  SHOWINSYSHEADER, CATEGORY)\
   {\
-diag::ENUM, DEFAULT_SEVERITY, CLASS, DiagnosticIDs::SFINAE, NOWERROR,  \
-SHOWINSYSHEADER, CATEGORY, GROUP, STR_SIZE(DESC, uin

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

[Nathan Froyd via Phabricator via cfe-commits]

froydnj requested review of this revision.
froydnj added a comment.

Throwing this back into the review queue.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81865/new/

https://reviews.llvm.org/D81865

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