chandlerc wrote:
> You might want to change the `DisableFree` default for library uses so that
> users don't need to specify `-no-disable-free`.
>
> ```
> // Clang calls BuryPointer on the internal AST and CodeGen-related elements
> like TargetMachine.
> // This will cause memory leaks if
rom 4e4ca5ab0f49252ea5a59c51fc1ddd0b43bcc5df Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Wed, 16 Apr 2025 22:57:18 +
Subject: [PATCH] Make the `-disable-free` flag more full featured
This lets us pass `-no-disable-free` to re-enable freeing memory for
example. This is especially helpful for library us
chandlerc wrote:
Follow-up PR as requested: #136271
https://github.com/llvm/llvm-project/pull/136213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rom 541894c25062d69b66ac27632e4f90021956de38 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Fri, 18 Apr 2025 06:55:15 +
Subject: [PATCH] Remove no-op visibility markers
Richard Smith noticed that these are overridden by the surrounding
visibility `let` region. Remove them to avoid confusion.
T
@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"],
"code-completion-with-fixits">,
def skip_function_bodies : Flag<["-"], "skip-function-bodies">,
HelpText<"Skip function bodies when possible">,
MarshallingInfoFlag>;
-def disable_free : Flag<["-"], "disab
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/136213
>From 6c53f36e9306d5abc50b9afcc1fe6a204d67c6e1 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Wed, 16 Apr 2025 22:57:18 +
Subject: [PATCH] Make the `-disable-free` flag more full featured
T
@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"],
"code-completion-with-fixits">,
def skip_function_bodies : Flag<["-"], "skip-function-bodies">,
HelpText<"Skip function bodies when possible">,
MarshallingInfoFlag>;
-def disable_free : Flag<["-"], "disab
@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"],
"code-completion-with-fixits">,
def skip_function_bodies : Flag<["-"], "skip-function-bodies">,
HelpText<"Skip function bodies when possible">,
MarshallingInfoFlag>;
-def disable_free : Flag<["-"], "disab
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/136213
___
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/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
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
@@ -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:
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
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:
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
___
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
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/123460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
@@ -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
@@ -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
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
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
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 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
@@ -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
chandlerc wrote:
Ping
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
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/123302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc edited
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
chandlerc wrote:
> Thanks @chandlerc this is great! I think I'd seen multiple reviews where
> someone saw the preprocessor tricks and suggested it was more suitable for
> tablegen. Too bad we hadn't done it before now, but many thanks to you for
> doing it.
>
> I was able to do some fairly mi
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
https://github.com/chandlerc edited
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:
@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:
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:
> 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
@@ -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
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
001
From: Chandler Carruth
Date: Fri, 17 Jan 2025 08:50:44 +
Subject: [PATCH] [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 to it rather than using a raw
`const char*`
t;for long strings.
>From da058f5c63bffa1459258092771874b7970da689 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::StringTable`
Previously, they used a hand-rolled Pascal-string encoding different
from all the othe
chandlerc wrote:
> > Is there any hope of upgrading MSVC? I know you were looking at that, but
> > not sure what progress happened there.
>
> I didn't go through with it and was hoping you would be able to find a
> work-around. I'll start talking to people to try and do a stop-gap update to
>
chandlerc wrote:
> > > @dyung -- this PR is updated with new fixes. NVPTX hopefully works and
> > > neither of my debugging checks fires. But there may still be some other
> > > failures I need to chase down, let me know?
> >
> >
> > Hmm, looks like there are likely to be ARM and Hexagon fail
chandlerc wrote:
> @dyung -- this PR is updated with new fixes. NVPTX hopefully works and
> neither of my debugging checks fires. But there may still be some other
> failures I need to chase down, let me know?
Hmm, looks like there are likely to be ARM and Hexagon failures remaining at
least.
chandlerc wrote:
@dyung -- this PR is updated with new fixes. NVPTX hopefully works and neither
of my debugging checks fires. But there may still be some other failures I need
to chase down, let me know?
https://github.com/llvm/llvm-project/pull/120534
_
chandlerc wrote:
> > ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
>
> Note that the PR doesn't actually change the lines that `clang-format`
> changes here, and the `clang-format` change makes these lines inconsistent
> with the rest of the file, so I intentionally did n
chandlerc wrote:
> ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
Note that the PR doesn't actually change the lines that `clang-format` changes
here, and the `clang-format` change makes these lines inconsistent with the
rest of the file, so I intentionally did not apply t
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/120861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> > @dyung -- Ok, my latest attempt to work around these MSVC issues is now
> > pushed to this PR. It also contains a commit of specifically debugging
> > hacks to try and extract more information from any failure here. If you
> > could try doing another build with the latest
chandlerc wrote:
@dyung -- Ok, my latest attempt to work around these MSVC issues is now pushed
to this PR. It also contains a commit of specifically debugging hacks to try
and extract more information from any failure here. If you could try doing
another build with the latest commit
([2ec750
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/121043
___
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/121043
___
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 `clang-debian-cpp20`
> running on `clang-debian-cpp20` while building `clang` at step 6
> "test-build-unified-tree-check-all".
>
> Full details are available at:
> https://lab.llvm.org/buildbot/#/builders/108/builds/7722
>
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
Sure, I use the Fish shell and have a bunch of command line tools that he
chandlerc wrote:
Updated to rebase on top-of-tree with #120831 merged. Re-ran all the scripts to
verify things.
Using a variation on the command from my
[comment](https://github.com/llvm/llvm-project/pull/120831#discussion_r1903059479)
on the other PR:
```fish
diff -u (rg '^TARGET' BuiltinsX
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/121043
>From 3314a7d9b2ab582769ce4b4438d24d31c280d9f8 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Tue, 24 Dec 2024 08:41:49 +
Subject: [PATCH] Bulk port 64-bit x86 builtins to TableGen
This PR foll
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/120831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Thanks, merging! I've put the script here for posterity:
https://gist.github.com/chandlerc/de807ea073beac351f87c660e1d4b7a0
https://github.com/llvm/llvm-project/pull/120831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/120831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
I've put the script in a gist here:
https://gist.github.com/chandlerc/de807ea073beac351f87c660e1d4b7a0
X-macros: the `BUILTIN(...)` macro invocations in an included file, where the
includer defines those macros to a specific pattern.
https://en.wikipedia.org/wiki/X_macro LLVM
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
Ok, PR updated with an explicit opt-in for OpenCL `long` type support.
S
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
This does maybe point at something that doesn't add much complexity -- I
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
Not sure -- the vast majority of x86 builtins use `O` for this.
It's a n
chandlerc wrote:
So looking through this, again, these are all done initially by automation. And
the simple current form of that automation preserves the order of builtins in
the `.def` file, and so can only merge groups when they are precisely adjacent.
FWIW, I can add logic to my script to i
chandlerc wrote:
Ping, rebased to top-of-tree.
@phoebewang -- I think you're the most relevant reviewer here. If the `O` vs.
`LL` thing is really a blocker despite the added information, I'd like to know
so I can explore options to switch back. All of the ones I've come up with add
complexity
chandlerc wrote:
Rebased -- ping for a review in the new year maybe? I think this one is pretty
simple...
https://github.com/llvm/llvm-project/pull/120861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/120861
>From e50a1dc121c00be4451d70b9bcdd1f3b6dbc98da Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Sat, 21 Dec 2024 23:42:57 +
Subject: [PATCH] Remove the `CustomEntry` escape hatch from buil
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/120835
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
For many of the comments -- this, like the previous PR, is script generated
based on the physical grouping of the current `.def` file. My preference would
be to land it without trying to massage to better utilize the TableGen
features, as I'd really like to get the first cut i
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:
> > 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 --
@@ -100,10 +244,17 @@ class Context {
/// Return the identifier name for the specified builtin,
/// e.g. "__builtin_abs".
- llvm::StringRef getName(unsigned ID) const { return getRecord(ID).Name; }
+ std::string getName(unsigned ID) const;
chandlerc wrot
@@ -100,10 +244,17 @@ class Context {
/// Return the identifier name for the specified builtin,
/// e.g. "__builtin_abs".
- llvm::StringRef getName(unsigned ID) const { return getRecord(ID).Name; }
+ std::string getName(unsigned ID) const;
+
+ /// Return the identifier
@@ -68,23 +70,144 @@ 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 commented:
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. @
@@ -68,23 +70,144 @@ 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
@@ -112,6 +112,16 @@ static constexpr std::array
MakeInfos(std::array Infos) {
return Infos;
}
+/// A shard of a target's builtins string table and info.
+///
+/// Target builtins are sharded across multiple tables due to different
+/// structures, origins, and also to impr
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:
> 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:
> > 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:
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:
> > * 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
.
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:
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
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:
> > > 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:
> > > > 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:
> 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:
> > > 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:
> 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:
> > > @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
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
1 - 100 of 566 matches
Mail list logo
