Talin
2014-Oct-06 18:08 UTC
[LLVMdev] LLVM features that ought to be surfaced in a higher-level language?
I've been out of touch with the LLVM community for a few years, and so I haven't kept up on all of the changes and improvements that have been added lately. I've been wondering if someone on this list would care to summarize what features of LLVM would be appropriate to expose as features of languages built on top of LLVM. In other words, if you were building a new LLVM-based language for general programming, how your language's feature set be affected by the capabilities already in LLVM? I'm focusing on language, and not compiler, features - so for example "faster code" is a compiler feature which doesn't usually affect the design of the language. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141006/d5ed5200/attachment.html>
Reid Kleckner
2014-Oct-06 18:29 UTC
[LLVMdev] LLVM features that ought to be surfaced in a higher-level language?
Some things come to mind: - the patchpoint and stackmap intrinsics used by WebKit - I added 'musttail', which can now be combined with varargs to implement a perfectly forwarding function that can modify some prefix of the arguments - comdat groups are now explicit in the IR, so if you have mergeable C++ template-like constructs you can now group related things together On Mon, Oct 6, 2014 at 11:08 AM, Talin <viridia at gmail.com> wrote:> I've been out of touch with the LLVM community for a few years, and so I > haven't kept up on all of the changes and improvements that have been added > lately. I've been wondering if someone on this list would care to summarize > what features of LLVM would be appropriate to expose as features of > languages built on top of LLVM. In other words, if you were building a new > LLVM-based language for general programming, how your language's feature > set be affected by the capabilities already in LLVM? I'm focusing on > language, and not compiler, features - so for example "faster code" is a > compiler feature which doesn't usually affect the design of the language. > > -- > -- Talin > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141006/67efc4c9/attachment.html>
Chris Lattner
2014-Oct-06 22:03 UTC
[LLVMdev] LLVM features that ought to be surfaced in a higher-level language?
On Oct 6, 2014, at 11:08 AM, Talin <viridia at gmail.com> wrote:> I've been out of touch with the LLVM community for a few years, and so I haven't kept up on all of the changes and improvements that have been added lately. I've been wondering if someone on this list would care to summarize what features of LLVM would be appropriate to expose as features of languages built on top of LLVM. In other words, if you were building a new LLVM-based language for general programming, how your language's feature set be affected by the capabilities already in LLVM? I'm focusing on language, and not compiler, features - so for example "faster code" is a compiler feature which doesn't usually affect the design of the language.Hi Talin, What specifically are you asking about here? Are you asking what LLVM features (e.g. arbitrary sized integers) would be interesting to expose in source languages? With Swift as an example, we weren’t constrained by LLVM, we just nudged LLVM and its infrastructure in the right direction over time. As one dumb example, Swift is why llvm::SourceMgr supports caret diagnostics, ranges and fixit hints. -Chris
David Chisnall
2014-Oct-07 08:03 UTC
[LLVMdev] LLVM features that ought to be surfaced in a higher-level language?
On 6 Oct 2014, at 19:29, Reid Kleckner <rnk at google.com> wrote:> - I added 'musttail', which can now be combined with varargs to implement a perfectly forwarding function that can modify some prefix of the argumentsI missed this when it went in. Does it rely on the target having the same calling convention for variadic and non-variadic functions? David