Author: chandlerc
Date: Tue Dec 29 21:40:23 2015
New Revision: 256615
URL: http://llvm.org/viewvc/llvm-project?rev=256615&view=rev
Log:
[ptr-traits] Add #includes of headers rather than forward declarations
for types which are used as pointees in PointerUnions, PointerIntPairs,
and DenseMap pointe
Author: chandlerc
Date: Wed Dec 30 00:21:02 2015
New Revision: 256629
URL: http://llvm.org/viewvc/llvm-project?rev=256629&view=rev
Log:
[ptr-traits] Some compilers (older Clang? unsure) on build bots need
this constructor to be out of line in order to not require the complete
type of TemplateDecl.
Author: chandlerc
Date: Wed Dec 30 00:38:29 2015
New Revision: 256630
URL: http://llvm.org/viewvc/llvm-project?rev=256630&view=rev
Log:
[ptr-traits] Add another complete type that is necessary for at least
some of the build bots. Still can't reproduce these failures locally.
Modified:
cfe/tru
Hey Chris, I just noticed that this option is only available when you build
Clang as a standalone project, as opposed to building all of LLVM. Was that
intentional? Is there any plan to support this in more normal whole-LLVM
builds? It seems substantially more useful for stuff like picking up
misco
chandlerc added inline comments.
Comment at: include/clang/Lex/HeaderSearchOptions.h:145
@@ -143,2 +144,3 @@
/// of computing the module hash.
- llvm::SetVector ModulesIgnoreMacros;
+ llvm::SetVector, std::set>
+ ModulesIgnoreMacros;
There is clearly a u
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
Sorry I was a bit slow -- was out when commented in Nov, and was slow catching
back up the past two weeks.
I've done some more testing, and the check-libomp is passing very nicely now!
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
Danny's OK is enough for me. LGTM
http://reviews.llvm.org/D15087
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
The substance of the patch LGTM. My nit picking is just on the wording of the
comment. =] Submit whenever.
Comment at: lib/Headers/__clang_cuda_runtime_wrapper.h:25-26
Uh, did you intend to commit this prior to Justin or others giving an LGTM?
On Fri, Dec 18, 2015 at 4:59 PM Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL256069: [CMake] Support a s
chandlerc wrote:
Discussion thread about the MSVC version change:
https://discourse.llvm.org/t/rfc-raising-minimum-msvc-version-by-one-patch-release/83490
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.
rom: Chandler Carruth
Date: Thu, 5 Dec 2024 03:11:42 +
Subject: [PATCH] Make the `CHECK` lines here resistent to `chandlerc`
Specifically, usernames containing `handle`, such as `chandlerc`, often
end up in paths, including the path of this test file which contains the
word `overflow`. Combined, t
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/118736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> LLVM Buildbot has detected a new failure on builder
> `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while building
> `clang` at step 7 "test-build-unified-tree-check-all".
>
> Full details are available at:
> [lab.llvm.org/buildbot#/builders/46/builds/9169](https:
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 9553557e87ec5d9ae5ce5636f6227150fcd080bc Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH 1/6] Switch builtin strings to use string tables
M
chandlerc wrote:
> Confirmed that this works on GCC now. I'd suggest to replace the use of
> StringLiteral::size with plain sizeof(). The build time overhead of going
> through StringLiteral here is substantial.
Sure. I was initially worried about the subtlety of this use of `sizeof`, but
tha
chandlerc wrote:
> > > > > LLVM Buildbot has detected a new failure on builder
> > > > > `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while
> > > > > building `clang` at step 7 "test-build-unified-tree-check-all".
> > > > > Full details are available at:
> > > > > [lab.llvm.org/buil
chandlerc wrote:
> > > LLVM Buildbot has detected a new failure on builder
> > > `llvm-clang-x86_64-sie-win` running on `sie-win-worker` while building
> > > `clang` at step 7 "test-build-unified-tree-check-all".
> > > Full details are available at:
> > > [lab.llvm.org/buildbot#/builders/46/bu
chandlerc wrote:
> Could the version of VC that we are using possibly have the issue with long
> strings that you mention? Is there a simple way to check that?
It's a compile time error, so no, that'd be really clear cut.
The only other thing I've seen is running out of heap, but that seems li
@@ -41,6 +41,10 @@ class LLVM_LIBRARY_VISIBILITY ARCTargetInfo : public
TargetInfo {
MacroBuilder &Builder) const override;
ArrayRef getTargetBuiltins() const override { return {}; }
chandlerc wrote:
Doh, yes. I meant to remove the
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 73a0b5c796881d1e52f8336eb69f678fd4c9f4c4 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH 1/2] Switch builtin strings to use string tables
M
chandlerc wrote:
The arm64-windows failures are from `DirectoryWatcherTest` that seems
exceedingly unlikely to be related.
I think the only real failures here are the originally discussed ones on the
one windows build bot. All the other windows bots seems to be OK here.
https://github.com/llv
chandlerc wrote:
> If you look for:
>
> ```
> FAILED:
> �[0mtools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CompileCommands.cpp.o
>
> ```
>
> In the build log that's the failure reason.
NP, and thanks. Sorry I missed that set of tests. Pushed a fix that makes
`check-clang-too
chandlerc wrote:
(FYI, I'm about to drop offline -- Hans, if you think it makes sense to revert
temporarily, please feel free to do so. I don't have a good sense of whether
the fallout here is enough to warrant that.)
https://github.com/llvm/llvm-project/pull/118734
___
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 73a0b5c796881d1e52f8336eb69f678fd4c9f4c4 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH 1/5] Switch builtin strings to use string tables
M
https://github.com/chandlerc commented:
> Fails to build with GCC:
Doh, I had hoped GCC would support this. Anyways, fixed back to just suppress
the diagnostic with Clang. Did some builds with GCC and everything seems fine,
and it doesn't seem like we're GCC warning clean these days anyways.
@@ -68,23 +69,156 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> > > Sure, I can test it. Just to confirm, what branch/commit should I be
> > > testing?
> >
> >
> > This PR has everything in it so you can just test it. There are 3 commits
> > on this branch that won't land here (they're under review in their own
> > PRs), but I've got t
chandlerc wrote:
Thanks @rnk !
I've fixed the one style nit (doh!) and a few surrounding variables.
I'm working on rebasing everything now.
But one specific question: would you prefer me to land as a series of commits
or a single squashed commit for the entire PR? I'm happy either way. My mil
@@ -482,17 +488,42 @@ void clang::EmitClangBuiltins(const RecordKeeper
&Records, raw_ostream &OS) {
for (const auto *BuiltinRecord :
Records.getAllDerivedDefinitions("AtomicBuiltin"))
collectBuiltins(BuiltinRecord, Builtins);
-
unsigned NumAtomicBuiltins = Buil
chandlerc wrote:
I know it's only been a few days, but pinging in the hope of landing this
week... This seems to finally be in a good state and is somewhat hard to keep
rebasing. Happy to do anything I can to help make review easier.
https://github.com/llvm/llvm-project/pull/120534
___
chandlerc wrote:
Given the benefit to binary size and compile time in things like `configure`
scripts, I'd certainly like to see it land...
Erich already reviewed an earlier version. Maybe @rnk can help with reviews?
https://github.com/llvm/llvm-project/pull/120534
chandlerc wrote:
> > But one specific question: would you prefer me to land as a series of
> > commits or a single squashed commit for the entire PR? I'm happy either
> > way. My mild preference is to prefer the series of commits, but open to
> > suggestions here.
>
> I would land it as the s
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/125979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
This should clean all of that up. I went
through to cross check the list of files and it looks correct now.
>From 26474c4278f466e4945e01cba46e00d484d6ffc5 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 6 Feb 2025 01:24:55 +
Subject: [PATCH] [StrTable] Fix modules build and clean
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+
@@ -80,15 +78,56 @@ class OptTable {
const char *AliasArgs;
const char *Values;
-StringRef getName() const {
- unsigned PrefixLength = Prefixes.empty() ? 0 : Prefixes[0].size();
- return PrefixedName.drop_front(PrefixLength);
+bool hasNoPrefix() const
@@ -845,13 +845,14 @@ MemoryBufferRef
LinkerDriver::convertResToCOFF(ArrayRef mbs,
// Create OptTable
+#define OPTTABLE_STR_TABLE_CODE
chandlerc wrote:
I have no idea. It took a lot of work to get even this to work, figuring out
each of the different ways
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/119198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Thanks for the careful review, merging! (And starting on the follow-ups!)
https://github.com/llvm/llvm-project/pull/119198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/119638
>From 333befd054fb5da81f1349c8eba7255aa4e3ec12 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Wed, 11 Dec 2024 15:59:35 -0800
Subject: [PATCH 1/2] Revert "Switch builtin strings to use strin
th forward given that no one else has thus far reproduced the issue.
>From 333befd054fb5da81f1349c8eba7255aa4e3ec12 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Wed, 11 Dec 2024 15:59:35 -0800
Subject: [PATCH] Revert "Switch builtin strings to use string tables
(#118734)&quo
chandlerc wrote:
> No real updates here, but our internal builder did catch up to this commit
> and we are seeing the same (and a lot more) failures when this commit is
> merged into our downstream codebase. I was kind of hoping that it would pass
> so that it might indicate that the problem m
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/119198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
@dyung - I believe this PR may be a credible path to address the issues hit
with your MSVC builders, would appreciate any help testing it in advance if
possible.
https://github.com/llvm/llvm-project/pull/120534
___
cfe-commits mailin
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/120534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/120534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> > > @dyung - I believe this PR may be a credible path to address the issues
> > > hit with your MSVC builders, would appreciate any help testing it in
> > > advance if possible.
> >
> >
> > Sure, I'll give it a try
>
> You seem to still be working on it, can you tell me wh
chandlerc wrote:
> I'll try it and let you know. Give me about an hour or so.
Awesome! But no huge rush, mostly just hoping this happens to dodge whatever
has been tripping up things here.
https://github.com/llvm/llvm-project/pull/120534
___
cfe-comm
chandlerc wrote:
Sorry, let's keep discussion on the original PR -- I'll go post there.
https://github.com/llvm/llvm-project/pull/119638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
So, the builder came back up, and is now passing without this landing...
Here is the first build after it came back up:
https://lab.llvm.org/buildbot/#/builders/46/builds/9173
And I went through the output and found a specific test that was failing, and
it seems to pass?
```
chandlerc wrote:
> I'm going to bring out Windows buildbot back online that was failing so that
> when you do submit the revert, the bot should go back to green. I am looking
> into this and will get back to you on the original bug when I find something.
So, the builder came back up, and is no
chandlerc wrote:
Build bot with the issue is now online and failing as expected, merging this
revert to get in green (we hope).
https://github.com/llvm/llvm-project/pull/119638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
chandlerc wrote:
I see the build bot up and with the original failure, going to merge the revert
to hopefully make sure it goes green after that.
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/119638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/119638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> That was a mistake. I originally was going to update the build bot to a later
> version of Visual Studio as while it wouldn't match our internal
> configuration, it was still useful to have some Windows coverage of the
> components we build/test. I then changed my mind and w
chandlerc wrote:
> > > I'll try it and let you know. Give me about an hour or so.
> >
> > Awesome! But no huge rush, mostly just hoping this happens to dodge
> > whatever has been tripping up things here.
>
> Sorry for the delay, but the failures still seem to be present. :( (The tests
> are
chandlerc wrote:
> Overall, I'm positive on this, and think this is beneficial. If this is
> something we can get to settle (I recognize this is probably what you were
> talking about with the RFC to increase the 'required MSVC version'), I'm all
> for it.
Yeah, this was the motivation.
Th
chandlerc wrote:
> > > Just to add some more details now that I've slept a bit...
> > > Previously there were errors in AArch64 and RISCV -- it'll be really
> > > useful to know if those are the only errors with this patch, are there
> > > new ones, and especially if the RISCV errors go away th
chandlerc wrote:
@dyung -- Could you try out
https://github.com/chandlerc/llvm-project/tree/shard-loongarch and see if that
works?
Notably, it includes one additional patch on top of this series:
https://github.com/chandlerc/llvm-project/commit/2d593288dc18c55307779ae82a18d024761356ad
This w
chandlerc wrote:
> > > > I'll try it and let you know. Give me about an hour or so.
> > >
> > >
> > > Awesome! But no huge rush, mostly just hoping this happens to dodge
> > > whatever has been tripping up things here.
> >
> >
> > Sorry for the delay, but the failures still seem to be presen
@@ -43,7 +43,8 @@ class LLVM_LIBRARY_VISIBILITY XCoreTargetInfo : public
TargetInfo {
void getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const override;
- ArrayRef getTargetBuiltins() const override;
+ std::pair>
chandlerc wrote:
No worries about delay, this gives me a credible target to resolve the rest of
the issues. I'll update this PR both to address review comments but also to try
and address the rest of the failures. Appreciate runs to validate these
updates. =]
https://github.com/llvm/llvm-proj
pointers to other
globals.
>From 02d05d256a1f5158be5bd924e66f820fee15ceec Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH] Switch builtin strings to use string tables
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The Clang bin
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 16e70ef753de962e76b5232912094a51ca24 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH] Switch builtin strings to use string tables
MIME-Vers
chandlerc wrote:
Updated to use the GCC diagnostic push the same as TableGen does for long
string literals. Also added Aaron to take a look as well (unless he's
comfortable already).
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits ma
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/118734
>From 73a0b5c796881d1e52f8336eb69f678fd4c9f4c4 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 28 Nov 2024 09:56:40 +
Subject: [PATCH] Switch builtin strings to use string tables
MIME-Vers
chandlerc wrote:
A long way from an expert on OpenCL, but it seems to not even have the concept
of `long long`, and `long` is defined as a 64-bit type (and just optional for
embedded stuff)?
https://registry.khronos.org/OpenCL/sdk/3.0/docs/man/html/scalarDataTypes.html
https://github.com/llvm
ng builtin handling respond appropriately.
This should produce identical results while preserving all the rest of the
structured representation in the builtin TableGen code.
>From b803cab4877afc4c9f1c140c4f86c048916ca2bf Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Sat, 21 Dec 2024 2
chandlerc wrote:
> > A long way from an expert on OpenCL, but it seems to not even have the
> > concept of `long long`, and `long` is defined as a 64-bit type (and just
> > optional for embedded stuff)?
> >
> > https://registry.khronos.org/OpenCL/sdk/3.0/docs/man/html/scalarDataTypes.html
>
>
chandlerc wrote:
> When I was still involved in X86 my recollection was we primarily used LLi.
> It looks like there was a large replacement of LLi with Oi here
> fa8cd7691ac28d07f6a127ed26f0dbe49699bd59.
Yeah, this patch makes me think the change to `Oi` here is ultimately correct,
and focus
chandlerc wrote:
> > I think I've addressed most of the review comments here at this point.
> > But maybe most excitingly, I think the latest version may dodge the issues
> > that have cropped up with MSVC -- both LoongArch and X86 fixes have been
> > incorporated that hopefully help. @dyung --
.
This refactoring is extracted out of #120534 as requested in code review.
>From ab211da29a4f5910e21ef626f6a9df448c910d55 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Sat, 21 Dec 2024 09:26:24 +
Subject: [PATCH] Factor common code for quoting a builtin name
This shows up in seve
chandlerc wrote:
> > * Systematically using `Oi` instead of `LLi` for the type `long long int`.
> > The `.def` file uses a mixture of `Oi` and `LLi`. I chose the shorter
> > encoding.
>
> The mixture use of `Oi` and `LLi` is a mess, but `Oi` has different meaning
> for OpenCL targets. I think
@@ -117,13 +121,13 @@ class OptTable {
private:
// A unified string table for these options. Individual strings are stored as
// null terminated C-strings at offsets within this table.
- const char *StrTable;
+ const StringTable *StrTable;
chandlerc wrote
@@ -33,25 +33,26 @@ using namespace llvm::opt;
namespace {
struct OptNameLess {
- const char *StrTable;
- ArrayRef PrefixesTable;
+ const StringTable *StrTable;
chandlerc wrote:
(same as above)
https://github.com/llvm/llvm-project/pull/123308
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/123308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Ping -- a week now with no review.
https://github.com/llvm/llvm-project/pull/122873
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> > I also so comments on the python script, but as I mentioned there, the
> > script is not code I'm suggesting to check in or maintain, merely
> > documenting for completeness. It was never written to be remotely readable
> > or clean, just to produce a verifiably equivalent
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/123548
>From ce7c655ceec7af22256967a9892ac00a9a2ae925 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 16 Jan 2025 21:29:40 +
Subject: [PATCH] [StrTable] Switch intrinsics to `StringTable` and w
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/123548
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Ping -- all the dependent changes have landed and this is ready to be reviewed
/ merged!
I've already had to update this as more string table using code landed, so I'd
like it to not wait too long...
https://github.com/llvm/llvm-project/pull/123548
___
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/123548
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Pushed an update that rebases on main, and more notably use an improved script
that preserves the grouping of builtins and the comments describing them. I
noticed that there were interesting and important comments here, so I reworked
things so we don't lose any information.
h
chandlerc wrote:
@dyung - OK, I think the current just-pushed version of this PR is worth
another test.
I've taught the TableGen string table emission to go back to working around the
MSVC issues using a different table form that we used to use in LLVM when MSVC
had a reliable error on it. It
chandlerc wrote:
> Some good news, everything seems to pass after your latest changes in this
> PR! I didn't believe it at first and did a clean rebuild and test to verify.
> In the end everything passed again.
>
> That being said, I am working on deploying an updated version of VS2019 to
> o
85ec017916d01f Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Fri, 17 Jan 2025 08:50:44 +
Subject: [PATCH 1/3] [StrTable] Switch the option parser to
`llvm::StringTable`
Now that we have a dedicated abstraction for string tables, switch the
option parser library's string table over
chandlerc wrote:
> You mention the performance tradeoff of pascal strings v null terminated ones
> doesn't seem too important - I guess that's based on some judgement about
> where/how these are used/where the strlens end up happening that you've
> looked into? Could you summarize that in a bi
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/123302
>From c78d4a2fd8d04aa79bab0c65044781aa0b8ca004 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Fri, 17 Jan 2025 08:31:45 +
Subject: [PATCH] Switch diagnostic group names to use `llvm::StringTa
@@ -51,6 +53,14 @@ class StringTable {
constexpr Offset() = default;
constexpr Offset(unsigned Value) : Value(Value) {}
+constexpr bool operator==(const Offset &RHS) const {
chandlerc wrote:
Doh, done. Forgot to go back to this after the iterator
@@ -51,28 +57,71 @@ class StringToOffsetTable {
return II->second;
}
- // Emit the string using string literal concatenation, for better readability
- // and searchability.
- void EmitStringLiteralDef(raw_ostream &OS, const Twine &Decl,
-co
chandlerc wrote:
Ping!
I've updated this to incorporate the changes in #123398 to the NVPTX.def file
this is replacing.
Adding the author & reviewers of that PR to this -- I'd really like to either
get this landed or figure out what other approach to use it avoid having to
continually update
@@ -51,28 +57,71 @@ class StringToOffsetTable {
return II->second;
}
- // Emit the string using string literal concatenation, for better readability
- // and searchability.
- void EmitStringLiteralDef(raw_ostream &OS, const Twine &Decl,
-co
chandlerc wrote:
Sounds good, and thanks for all the reviews!
https://github.com/llvm/llvm-project/pull/123548
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/123548
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/123460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
201 - 300 of 566 matches
Mail list logo
