llvmbot wrote:
>If you want to backport this, you need to add the PR to the milestone and
>comment
>
>`/cherry-pick...`
>
>Then the bot should open a PR (or it'll tell you if it failed to cherry-pick,
>and how to proceed from there).
Error: Command failed due to missing milestone.
https
h-vetinari wrote:
If you want to backport this, you need to add the PR to the milestone and
comment
`/cherry-pick...`
Then the bot should open a PR (or it'll tell you if it failed to cherry-pick,
and how to proceed from there).
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
rnk 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 six-patch stack in thi
phoebewang wrote:
> I proposed this at one point, and someone from Intel assured me that these
> long repetitive instructions and intrinsics are hand-maintained. It must be
> true at some level.
I believe it's not me, though I don't like the changes at the beginning either.
Anyway, with @chan
@@ -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
https://github.com/rnk 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
@@ -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
https://github.com/rnk approved this pull request.
Thanks for optimizing the builtins! I feel like builtins have grown
significantly since adding RISC-V and ARM MVE intrinsics, and few people until
now have stopped to re-evaluate how we represent these things.
While I was watching these clearl
Andarwinux wrote:
https://github.com/llvm/llvm-project/pull/125367
RC1 coming soon
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:
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
h-vetinari wrote:
You'd have to merge and request a backport pretty quickly. Historically
features could still be argued to land between rc1 (which is imminent) and rc2,
but the windows is definitely closing fast
https://github.com/llvm/llvm-project/pull/120534
Andarwinux wrote:
Will LLVM 20 miss this?
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:
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
___
dyung wrote:
> All of the dependent changes have landed, and I've re-structured this patch
> series to hopefully be easier to review. I still don't have a good way to
> land this incrementally, as the tools to work around MSVC limitations are
> only available when using TableGen-ed string tabl
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
>
dyung 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 a
later version
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
dyung 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
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:
> > @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
dyung 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
> ([
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
dyung wrote:
``
> Hmm, this looks like I just didn't fix "enough".
>
> I've sent out #121043 and rebased this PR on top of that as well. Can you
> take another spin?
>
> This PR should be the right branch, incorporating all the other changes.
I've built and tested this PR (I think) and it doe
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
dyung 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 them all here so you c
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 --
dyung 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 -- if you c
@@ -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
h-vetinari wrote:
I've [tested](https://github.com/conda-forge/clangdev-feedstock/pull/333) this
PR (as of 2bcc4e5f7043dab1ef673dd20b38009363db51db) in our infrastructure and
can confirm that things run fine with VS2019 again. Thanks a lot for reworking
this! 🙏
https://github.com/llvm/llvm-p
dyung 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. =]
Definitely happy to help out
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
dyung 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:
> [chandlerc@2d59328](https://github.com/chandlerc/llvm-project/commit/2d593288dc18c5530777
dyung 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:
> [chandlerc@2d59328](https://github.com/chandlerc/llvm-project/commit/2d593288dc18c5530777
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
https://github.com/efriedma-quic 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/efriedma-quic 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
@@ -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;
efriedma-quic
@@ -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
dyung 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 fail
dyung 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
@@ -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:
> > > > 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
dyung 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 still running, but
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
dyung 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, c
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
dyung 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 which commit I should try
dyung 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
https://github.com/llvm/llvm-project/pull/120534
__
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
63 matches
Mail list logo
