LLVM Weekly - #1, Jan 6th 2014
=============================
Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter (published
every Monday) covering developments in LLVM, Clang, and related projects.
I've
been a long time lurker on the LLVM and Clang mailing lists and have been
using LLVM extensively in my PhD research for the past 4 years. I thought it
might be worthwhile to produce something to help keep track of what's going
on
in LLVM development, and here we are. I'm very open to suggestions and will
probably play a bit with the format and content over the next few weeks. I'd
also be very grateful for any suggestions of things to mention or cover.
Subscribe to future issues at <http://llvmweekly.org>, and please pass it
on
to anyone else you think may be interested. Please send any tips or feedback
to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter.
Find the HTML version of this issue at http://llvmweekly.org/issue/1
## News and articles from around the web
LLVM 3.4 was released
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>.
The release notes do a far better and more thorough job of summarising the key
changes than I could, so I point you there for more information.
EuroLLVM 2014 has been announced. It will take place April 7th-8th in
Edinburgh Scotland. Registration will open soon, now is the time to submit
your proposals for talks, workshops, lightning talks or posters. The call for
participation is at
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69221> and the
homepage for the event is at <http://llvm.org/devmtg/2014-04/>.
In a recent mailing list post I came across a link to this rather excellent
article on mapping high-level constructions to LLVM IR by Mikael Lyngvig.
<http://llvm.lyngvig.org/Articles/Mapping-High-Level-Constructs-to-LLVM-IR>.
The document is already in a good state, but Mikael is inviting review or
contributions, particularly from those who implement frontends of higher level
languages targetting LLVM IR.
Andrew Wilkins writes about recent changes to llgo, a Go frontend for LLVM.
<http://blog.awilkins.id.au/2014/01/llgo-on-ssa.html>
DZone predicts the end of the GNU gcc era
<http://java.dzone.com/articles/2014-look-magic-crystal-ball>
Phoronix published a series of benchmarks comparing Clang 3.4 performance
against GCC 4.9
<http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1>
## On the mailing lists
* Rafael Espíndola removed support for the 's' modifier in a DataLayout
specification in commit [r198287](http://llvm-reviews.chandlerc.com/rL198287)
and so writes how to work around this if your out of tree target relied on
that modifier
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69143>
* Chandler Carruth asks a question about flags for instructions in .td files
<http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118>. From the
answers, it seems like confusion can arise from the fact flags don't need to
be listed explicitly if they are inferred from patterns. Hal Finkel suggests
auditing the generated tablegen output directly.
* Jon Pry has posted an RFC suggesting to change the datalayout for the Radeon
R600 backend
<http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69130>.
The problem is that the r600 datalayout description currently claims native
integer widths of 32 and 64 bit, but support for 64 bit arithmetic is actually
limited to getelementptr-like load/store operations (although this point is
debated in replies to the thread). The patch proposes to simply claim native
32 bit integer width only, though alternative solutions are proposed in thread
responses.
* Andrew Trick outlines an algorithm to estimate cycles taken on an
out-of-order core
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69145>
* Build bot fatigue
<http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69103> is causing
problems. In short the build bots are sending too many messages, and slow
servers keep on sending messages for issues that were fixed already resulting
in a low signal to noise ratio. There was a suggestion to move to the phased
builder infrastructure as used by Apple. There were additional complaints from
Alp about large numbers of emails from ARM buildbots about errors such as out
of disk <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200>.
Renato Golin responds explaining that due to the lack of commercial ARM server
hardware they have to rely on development boards or consumer laptops, which
may not be the most reliable under heavy load.
* Snehasish Kumar asks about using DependenceAnalysis to find both
loop-independent and loop-carried dependences, receiving some useful
responses.
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094>
* David Fang posts a summary of the current status of the PowerPC-Darwin ports
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69196>. An
extensively detailed status page is also available at
<http://www.csl.cornell.edu/~fang/sw/llvm/>
* Swarup Kumar Sahoo points to the current giri code
<https://github.com/liuml07/giri> in response to a question about how to
trace
every value and address used by a program.
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69150>
* Tim Northover provides a straight forward overview of what to do in order to
disable loop unrolling and function inlining, and where the source to the
relevant passes can be found
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69213>
* Michael Schlottke asks for advice about LibTools vs LibClang+Python for some
C++ refactoring tasks.
<http://article.gmane.org/gmane.comp.compilers.clang.devel/34050> The
mailing
list is overwhelmingly in favour of using LibTooling, though it does have the
downside that nobody has produced Python bindings to it yet.
## LLVM commits
Warning: this is an opinionated, unscientific highlighting of certain LLVM
commits. I may have missed your favourite change - apologies.
* An initial ASM parser was added to the SPARC backend
<http://llvm-reviews.chandlerc.com/rL198484>. The backend also learned to
handle atomics loads/stores <http://llvm-reviews.chandlerc.com/rL198286>.
* Various AVX512 (currently only available in Xeon Phi CPUs) intrinsics were
added <http://llvm-reviews.chandlerc.com/rL198277>,
<http://llvm-reviews.chandlerc.com/rL198557>
* ARM: For compatibility with GNU as, aliases for old (deprecated) FP
mnemonics were added <http://llvm-reviews.chandlerc.com/rL198172>.
Additionally, softvfp was added to the list of supported FPU names
<http://llvm-reviews.chandlerc.com/rL198313>
* The LLVM mangler, used to determin the symbol name of a GlobalValue no
longer requires linking with Target. This means the DataLayout now contains a
specification for the name mangling behaviour.
<http://llvm-reviews.chandlerc.com/rL198438>
* tryInstructionSplit() has been made less aggressive
<http://llvm-reviews.chandlerc.com/rL198369>
* In the world of tablegen, a bug with the use of multiclass parameters was
fixed <http://llvm-reviews.chandlerc.com/rL198348>
* A confusion between `Value*` identify and 'value' equivalence was
corrected
in BasicAA <http://llvm-reviews.chandlerc.com/rL198290>
## Clang commits
* RecursiveASTVisitor and DataRecursiveASTVisitor learned to visit attributes
<http://llvm-reviews.chandlerc.com/rL198224>,
<http://llvm-reviews.chandlerc.com/rL198249>
* ExpectAndConsume will diagnose more errors automatically
<http://llvm-reviews.chandlerc.com/rL198270>
* The formatter gained an option to avoid splitting certain sorts of comments
which have special meaning (e.g. pragmas) across multiple lines
<http://llvm-reviews.chandlerc.com/rL198310>. It can also format short
enums
on to a single line <http://llvm-reviews.chandlerc.com/rL198558>
* The VBTableBuilder class was moved from CodeGen to AST with the long-term
goal of using it to compute virtual fuction table names
<http://llvm-reviews.chandlerc.com/rL198380>
* CreateAnalysisConsumer is added to the static analyzer's public interface
as
a way to get at its ASTConsumer.
<http://llvm-reviews.chandlerc.com/rL198426>
* Virtual base class table mangling is now more compatible with MSVC202+
<http://llvm-reviews.chandlerc.com/rL198462>
* The IdempotentOperations checker was killed as it has various known issues
and nobody has come forwards to fix them.
<http://llvm-reviews.chandlerc.com/rL198476>
* `dump()` function definitions are now only marked as used in debug builds.
This will enable more stripping of dead code in release builds resulting in
smaller filesize. <http://llvm-reviews.chandlerc.com/rL198489>
* Previously, clang could be tortured by providing a K and R style function
declaration with a missing semicolon, e.g. `void knrNoSemi(i) int i { }` which
would result in a long stream of errors covering the rest of the input file.
It now recognises this error and presents a single error
<http://llvm-reviews.chandlerc.com/rL198540>.
## Other project commits
* Building libclc with LLVM 3.5 was fixed
<http://llvm-reviews.chandlerc.com/rL198167>
* In libcxx, the clz/ctz family of functions are now implemented for when
building with Visual C++ on Win32 or Win64.
<http://llvm-reviews.chandlerc.com/rL198481>
* The PollyCananicalizePass was introduced. This is a ModulePass that
schedules the Polly canonicalization passes.
<http://llvm-reviews.chandlerc.com/rL198376>
Hey neat, I've been wanting something like this for a while. Thanks! -eric On Mon Jan 06 2014 at 2:51:31 PM, Alex Bradbury <asb at asbradbury.org> wrote:> LLVM Weekly - #1, Jan 6th 2014 > =============================> > Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter > (published > every Monday) covering developments in LLVM, Clang, and related projects. > I've > been a long time lurker on the LLVM and Clang mailing lists and have been > using LLVM extensively in my PhD research for the past 4 years. I thought > it > might be worthwhile to produce something to help keep track of what's > going on > in LLVM development, and here we are. I'm very open to suggestions and will > probably play a bit with the format and content over the next few weeks. > I'd > also be very grateful for any suggestions of things to mention or cover. > Subscribe to future issues at <http://llvmweekly.org>, and please pass it > on > to anyone else you think may be interested. Please send any tips or > feedback > to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. > > Find the HTML version of this issue at http://llvmweekly.org/issue/1 > > ## News and articles from around the web > > LLVM 3.4 was released <http://llvm.org/releases/3.4/docs/ReleaseNotes.html > >. > The release notes do a far better and more thorough job of summarising the > key > changes than I could, so I point you there for more information. > > EuroLLVM 2014 has been announced. It will take place April 7th-8th in > Edinburgh Scotland. Registration will open soon, now is the time to submit > your proposals for talks, workshops, lightning talks or posters. The call > for > participation is at > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69221> and the > homepage for the event is at <http://llvm.org/devmtg/2014-04/>. > > In a recent mailing list post I came across a link to this rather excellent > article on mapping high-level constructions to LLVM IR by Mikael Lyngvig. > <http://llvm.lyngvig.org/Articles/Mapping-High-Level-Constructs-to-LLVM-IR > >. > The document is already in a good state, but Mikael is inviting review or > contributions, particularly from those who implement frontends of higher > level > languages targetting LLVM IR. > > Andrew Wilkins writes about recent changes to llgo, a Go frontend for LLVM. > <http://blog.awilkins.id.au/2014/01/llgo-on-ssa.html> > > DZone predicts the end of the GNU gcc era > <http://java.dzone.com/articles/2014-look-magic-crystal-ball> > > Phoronix published a series of benchmarks comparing Clang 3.4 performance > against GCC 4.9 > <http://www.phoronix.com/scan.php?page=article&item=llvm34_ > gcc49_compilers&num=1> > > ## On the mailing lists > > * Rafael Espíndola removed support for the 's' modifier in a DataLayout > specification in commit [r198287](http://llvm-reviews. > chandlerc.com/rL198287) > and so writes how to work around this if your out of tree target relied on > that modifier <http://article.gmane.org/gmane.comp.compilers.llvm. > devel/69143> > > * Chandler Carruth asks a question about flags for instructions in .td > files > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118>. From the > answers, it seems like confusion can arise from the fact flags don't need > to > be listed explicitly if they are inferred from patterns. Hal Finkel > suggests > auditing the generated tablegen output directly. > > * Jon Pry has posted an RFC suggesting to change the datalayout for the > Radeon > R600 backend <http://thread.gmane.org/gmane.comp.compilers.llvm. > devel/69130>. > The problem is that the r600 datalayout description currently claims native > integer widths of 32 and 64 bit, but support for 64 bit arithmetic is > actually > limited to getelementptr-like load/store operations (although this point is > debated in replies to the thread). The patch proposes to simply claim > native > 32 bit integer width only, though alternative solutions are proposed in > thread > responses. > > * Andrew Trick outlines an algorithm to estimate cycles taken on an > out-of-order core > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69145> > > * Build bot fatigue > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69103> is causing > problems. In short the build bots are sending too many messages, and slow > servers keep on sending messages for issues that were fixed already > resulting > in a low signal to noise ratio. There was a suggestion to move to the > phased > builder infrastructure as used by Apple. There were additional complaints > from > Alp about large numbers of emails from ARM buildbots about errors such as > out > of disk <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200>. > Renato Golin responds explaining that due to the lack of commercial ARM > server > hardware they have to rely on development boards or consumer laptops, which > may not be the most reliable under heavy load. > > * Snehasish Kumar asks about using DependenceAnalysis to find both > loop-independent and loop-carried dependences, receiving some useful > responses. <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094 > > > > * David Fang posts a summary of the current status of the PowerPC-Darwin > ports > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69196>. An > extensively detailed status page is also available at > <http://www.csl.cornell.edu/~fang/sw/llvm/> > > * Swarup Kumar Sahoo points to the current giri code > <https://github.com/liuml07/giri> in response to a question about how to > trace > every value and address used by a program. > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69150> > > * Tim Northover provides a straight forward overview of what to do in > order to > disable loop unrolling and function inlining, and where the source to the > relevant passes can be found > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69213> > > * Michael Schlottke asks for advice about LibTools vs LibClang+Python for > some > C++ refactoring tasks. > <http://article.gmane.org/gmane.comp.compilers.clang.devel/34050> The > mailing > list is overwhelmingly in favour of using LibTooling, though it does have > the > downside that nobody has produced Python bindings to it yet. > > ## LLVM commits > > Warning: this is an opinionated, unscientific highlighting of certain LLVM > commits. I may have missed your favourite change - apologies. > > * An initial ASM parser was added to the SPARC backend > <http://llvm-reviews.chandlerc.com/rL198484>. The backend also learned to > handle atomics loads/stores <http://llvm-reviews.chandlerc.com/rL198286>. > > * Various AVX512 (currently only available in Xeon Phi CPUs) intrinsics > were > added <http://llvm-reviews.chandlerc.com/rL198277>, > <http://llvm-reviews.chandlerc.com/rL198557> > > * ARM: For compatibility with GNU as, aliases for old (deprecated) FP > mnemonics were added <http://llvm-reviews.chandlerc.com/rL198172>. > Additionally, softvfp was added to the list of supported FPU names > <http://llvm-reviews.chandlerc.com/rL198313> > > * The LLVM mangler, used to determin the symbol name of a GlobalValue no > longer requires linking with Target. This means the DataLayout now > contains a > specification for the name mangling behaviour. > <http://llvm-reviews.chandlerc.com/rL198438> > > * tryInstructionSplit() has been made less aggressive > <http://llvm-reviews.chandlerc.com/rL198369> > > * In the world of tablegen, a bug with the use of multiclass parameters was > fixed <http://llvm-reviews.chandlerc.com/rL198348> > > * A confusion between `Value*` identify and 'value' equivalence was > corrected > in BasicAA <http://llvm-reviews.chandlerc.com/rL198290> > > ## Clang commits > > * RecursiveASTVisitor and DataRecursiveASTVisitor learned to visit > attributes > <http://llvm-reviews.chandlerc.com/rL198224>, > <http://llvm-reviews.chandlerc.com/rL198249> > > * ExpectAndConsume will diagnose more errors automatically > <http://llvm-reviews.chandlerc.com/rL198270> > > * The formatter gained an option to avoid splitting certain sorts of > comments > which have special meaning (e.g. pragmas) across multiple lines > <http://llvm-reviews.chandlerc.com/rL198310>. It can also format short > enums > on to a single line <http://llvm-reviews.chandlerc.com/rL198558> > > * The VBTableBuilder class was moved from CodeGen to AST with the long-term > goal of using it to compute virtual fuction table names > <http://llvm-reviews.chandlerc.com/rL198380> > > * CreateAnalysisConsumer is added to the static analyzer's public > interface as > a way to get at its ASTConsumer. <http://llvm-reviews. > chandlerc.com/rL198426> > > * Virtual base class table mangling is now more compatible with MSVC202+ > <http://llvm-reviews.chandlerc.com/rL198462> > > * The IdempotentOperations checker was killed as it has various known > issues > and nobody has come forwards to fix them. > <http://llvm-reviews.chandlerc.com/rL198476> > > * `dump()` function definitions are now only marked as used in debug > builds. > This will enable more stripping of dead code in release builds resulting in > smaller filesize. <http://llvm-reviews.chandlerc.com/rL198489> > > * Previously, clang could be tortured by providing a K and R style function > declaration with a missing semicolon, e.g. `void knrNoSemi(i) int i { }` > which > would result in a long stream of errors covering the rest of the input > file. > It now recognises this error and presents a single error > <http://llvm-reviews.chandlerc.com/rL198540>. > > ## Other project commits > > * Building libclc with LLVM 3.5 was fixed > <http://llvm-reviews.chandlerc.com/rL198167> > > * In libcxx, the clz/ctz family of functions are now implemented for when > building with Visual C++ on Win32 or Win64. > <http://llvm-reviews.chandlerc.com/rL198481> > > * The PollyCananicalizePass was introduced. This is a ModulePass that > schedules the Polly canonicalization passes. > <http://llvm-reviews.chandlerc.com/rL198376> > > _______________________________________________ > 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/20140106/a88556ef/attachment.html>
Awesome, super useful. Thanks so much for doing this! -Greg On Mon, Jan 6, 2014 at 3:16 PM, Eric Christopher <echristo at gmail.com> wrote:> Hey neat, I've been wanting something like this for a while. > > Thanks! > > -eric > > On Mon Jan 06 2014 at 2:51:31 PM, Alex Bradbury <asb at asbradbury.org> wrote: >> >> LLVM Weekly - #1, Jan 6th 2014 >> =============================>> >> Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter >> (published >> every Monday) covering developments in LLVM, Clang, and related projects. >> I've >> been a long time lurker on the LLVM and Clang mailing lists and have been >> using LLVM extensively in my PhD research for the past 4 years. I thought >> it >> might be worthwhile to produce something to help keep track of what's >> going on >> in LLVM development, and here we are. I'm very open to suggestions and >> will >> probably play a bit with the format and content over the next few weeks. >> I'd >> also be very grateful for any suggestions of things to mention or cover. >> Subscribe to future issues at <http://llvmweekly.org>, and please pass it >> on >> to anyone else you think may be interested. Please send any tips or >> feedback >> to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. >> >> Find the HTML version of this issue at http://llvmweekly.org/issue/1 >> >> ## News and articles from around the web >> >> LLVM 3.4 was released >> <http://llvm.org/releases/3.4/docs/ReleaseNotes.html>. >> The release notes do a far better and more thorough job of summarising the >> key >> changes than I could, so I point you there for more information. >> >> EuroLLVM 2014 has been announced. It will take place April 7th-8th in >> Edinburgh Scotland. Registration will open soon, now is the time to submit >> your proposals for talks, workshops, lightning talks or posters. The call >> for >> participation is at >> <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69221> and the >> homepage for the event is at <http://llvm.org/devmtg/2014-04/>. >> >> In a recent mailing list post I came across a link to this rather >> excellent >> article on mapping high-level constructions to LLVM IR by Mikael Lyngvig. >> >> <http://llvm.lyngvig.org/Articles/Mapping-High-Level-Constructs-to-LLVM-IR>. >> The document is already in a good state, but Mikael is inviting review or >> contributions, particularly from those who implement frontends of higher >> level >> languages targetting LLVM IR. >> >> Andrew Wilkins writes about recent changes to llgo, a Go frontend for >> LLVM. >> <http://blog.awilkins.id.au/2014/01/llgo-on-ssa.html> >> >> DZone predicts the end of the GNU gcc era >> <http://java.dzone.com/articles/2014-look-magic-crystal-ball> >> >> Phoronix published a series of benchmarks comparing Clang 3.4 performance >> against GCC 4.9 >> >> <http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1> >> >> ## On the mailing lists >> >> * Rafael Espíndola removed support for the 's' modifier in a DataLayout >> specification in commit >> [r198287](http://llvm-reviews.chandlerc.com/rL198287) >> and so writes how to work around this if your out of tree target relied on >> that modifier >> <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69143> >> >> * Chandler Carruth asks a question about flags for instructions in .td >> files >> <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118>. From the >> answers, it seems like confusion can arise from the fact flags don't need >> to >> be listed explicitly if they are inferred from patterns. Hal Finkel >> suggests >> auditing the generated tablegen output directly. >> >> * Jon Pry has posted an RFC suggesting to change the datalayout for the >> Radeon >> R600 backend >> <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69130>. >> The problem is that the r600 datalayout description currently claims >> native >> integer widths of 32 and 64 bit, but support for 64 bit arithmetic is >> actually >> limited to getelementptr-like load/store operations (although this point >> is >> debated in replies to the thread). The patch proposes to simply claim >> native >> 32 bit integer width only, though alternative solutions are proposed in >> thread >> responses. >> >> * Andrew Trick outlines an algorithm to estimate cycles taken on an >> out-of-order core >> <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69145> >> >> * Build bot fatigue >> <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69103> is causing >> problems. In short the build bots are sending too many messages, and slow >> servers keep on sending messages for issues that were fixed already >> resulting >> in a low signal to noise ratio. There was a suggestion to move to the >> phased >> builder infrastructure as used by Apple. There were additional complaints >> from >> Alp about large numbers of emails from ARM buildbots about errors such as >> out >> of disk <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200>. >> Renato Golin responds explaining that due to the lack of commercial ARM >> server >> hardware they have to rely on development boards or consumer laptops, >> which >> may not be the most reliable under heavy load. >> >> * Snehasish Kumar asks about using DependenceAnalysis to find both >> loop-independent and loop-carried dependences, receiving some useful >> responses. >> <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094> >> >> * David Fang posts a summary of the current status of the PowerPC-Darwin >> ports >> <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69196>. An >> extensively detailed status page is also available at >> <http://www.csl.cornell.edu/~fang/sw/llvm/> >> >> * Swarup Kumar Sahoo points to the current giri code >> <https://github.com/liuml07/giri> in response to a question about how to >> trace >> every value and address used by a program. >> <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69150> >> >> * Tim Northover provides a straight forward overview of what to do in >> order to >> disable loop unrolling and function inlining, and where the source to the >> relevant passes can be found >> <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69213> >> >> * Michael Schlottke asks for advice about LibTools vs LibClang+Python for >> some >> C++ refactoring tasks. >> <http://article.gmane.org/gmane.comp.compilers.clang.devel/34050> The >> mailing >> list is overwhelmingly in favour of using LibTooling, though it does have >> the >> downside that nobody has produced Python bindings to it yet. >> >> ## LLVM commits >> >> Warning: this is an opinionated, unscientific highlighting of certain LLVM >> commits. I may have missed your favourite change - apologies. >> >> * An initial ASM parser was added to the SPARC backend >> <http://llvm-reviews.chandlerc.com/rL198484>. The backend also learned to >> handle atomics loads/stores <http://llvm-reviews.chandlerc.com/rL198286>. >> >> * Various AVX512 (currently only available in Xeon Phi CPUs) intrinsics >> were >> added <http://llvm-reviews.chandlerc.com/rL198277>, >> <http://llvm-reviews.chandlerc.com/rL198557> >> >> * ARM: For compatibility with GNU as, aliases for old (deprecated) FP >> mnemonics were added <http://llvm-reviews.chandlerc.com/rL198172>. >> Additionally, softvfp was added to the list of supported FPU names >> <http://llvm-reviews.chandlerc.com/rL198313> >> >> * The LLVM mangler, used to determin the symbol name of a GlobalValue no >> longer requires linking with Target. This means the DataLayout now >> contains a >> specification for the name mangling behaviour. >> <http://llvm-reviews.chandlerc.com/rL198438> >> >> * tryInstructionSplit() has been made less aggressive >> <http://llvm-reviews.chandlerc.com/rL198369> >> >> * In the world of tablegen, a bug with the use of multiclass parameters >> was >> fixed <http://llvm-reviews.chandlerc.com/rL198348> >> >> * A confusion between `Value*` identify and 'value' equivalence was >> corrected >> in BasicAA <http://llvm-reviews.chandlerc.com/rL198290> >> >> ## Clang commits >> >> * RecursiveASTVisitor and DataRecursiveASTVisitor learned to visit >> attributes >> <http://llvm-reviews.chandlerc.com/rL198224>, >> <http://llvm-reviews.chandlerc.com/rL198249> >> >> * ExpectAndConsume will diagnose more errors automatically >> <http://llvm-reviews.chandlerc.com/rL198270> >> >> * The formatter gained an option to avoid splitting certain sorts of >> comments >> which have special meaning (e.g. pragmas) across multiple lines >> <http://llvm-reviews.chandlerc.com/rL198310>. It can also format short >> enums >> on to a single line <http://llvm-reviews.chandlerc.com/rL198558> >> >> * The VBTableBuilder class was moved from CodeGen to AST with the >> long-term >> goal of using it to compute virtual fuction table names >> <http://llvm-reviews.chandlerc.com/rL198380> >> >> * CreateAnalysisConsumer is added to the static analyzer's public >> interface as >> a way to get at its ASTConsumer. >> <http://llvm-reviews.chandlerc.com/rL198426> >> >> * Virtual base class table mangling is now more compatible with MSVC202+ >> <http://llvm-reviews.chandlerc.com/rL198462> >> >> * The IdempotentOperations checker was killed as it has various known >> issues >> and nobody has come forwards to fix them. >> <http://llvm-reviews.chandlerc.com/rL198476> >> >> * `dump()` function definitions are now only marked as used in debug >> builds. >> This will enable more stripping of dead code in release builds resulting >> in >> smaller filesize. <http://llvm-reviews.chandlerc.com/rL198489> >> >> * Previously, clang could be tortured by providing a K and R style >> function >> declaration with a missing semicolon, e.g. `void knrNoSemi(i) int i { }` >> which >> would result in a long stream of errors covering the rest of the input >> file. >> It now recognises this error and presents a single error >> <http://llvm-reviews.chandlerc.com/rL198540>. >> >> ## Other project commits >> >> * Building libclc with LLVM 3.5 was fixed >> <http://llvm-reviews.chandlerc.com/rL198167> >> >> * In libcxx, the clz/ctz family of functions are now implemented for when >> building with Visual C++ on Win32 or Win64. >> <http://llvm-reviews.chandlerc.com/rL198481> >> >> * The PollyCananicalizePass was introduced. This is a ModulePass that >> schedules the Polly canonicalization passes. >> <http://llvm-reviews.chandlerc.com/rL198376> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
This is great! Reminds me of kerneltrap.org ... :) Someone is still trying to review that at http://kerneltrap.net ! Sameer.> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Alex Bradbury > Sent: Tuesday, January 07, 2014 4:19 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] LLVM Weekly - #1, Jan 6th 2014 > > LLVM Weekly - #1, Jan 6th 2014 > =============================> > Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter (published > every Monday) covering developments in LLVM, Clang, and related projects. I've > been a long time lurker on the LLVM and Clang mailing lists and have been > using LLVM extensively in my PhD research for the past 4 years. I thought it > might be worthwhile to produce something to help keep track of what's going > on > in LLVM development, and here we are. I'm very open to suggestions and will > probably play a bit with the format and content over the next few weeks. I'd > also be very grateful for any suggestions of things to mention or cover. > Subscribe to future issues at <http://llvmweekly.org>, and please pass it on > to anyone else you think may be interested. Please send any tips or feedback > to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. > > Find the HTML version of this issue at http://llvmweekly.org/issue/1 > > ## News and articles from around the web > > LLVM 3.4 was released <http://llvm.org/releases/3.4/docs/ReleaseNotes.html>. > The release notes do a far better and more thorough job of summarising the key > changes than I could, so I point you there for more information. > > EuroLLVM 2014 has been announced. It will take place April 7th-8th in > Edinburgh Scotland. Registration will open soon, now is the time to submit > your proposals for talks, workshops, lightning talks or posters. The call for > participation is at > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69221> and the > homepage for the event is at <http://llvm.org/devmtg/2014-04/>. > > In a recent mailing list post I came across a link to this rather excellent > article on mapping high-level constructions to LLVM IR by Mikael Lyngvig. > <http://llvm.lyngvig.org/Articles/Mapping-High-Level-Constructs-to-LLVM-IR>. > The document is already in a good state, but Mikael is inviting review or > contributions, particularly from those who implement frontends of higher level > languages targetting LLVM IR. > > Andrew Wilkins writes about recent changes to llgo, a Go frontend for LLVM. > <http://blog.awilkins.id.au/2014/01/llgo-on-ssa.html> > > DZone predicts the end of the GNU gcc era > <http://java.dzone.com/articles/2014-look-magic-crystal-ball> > > Phoronix published a series of benchmarks comparing Clang 3.4 performance > against GCC 4.9 > <http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compi > lers&num=1> > > ## On the mailing lists > > * Rafael Espíndola removed support for the 's' modifier in a DataLayout > specification in commit [r198287](http://llvm- > reviews.chandlerc.com/rL198287) > and so writes how to work around this if your out of tree target relied on > that modifier > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69143> > > * Chandler Carruth asks a question about flags for instructions in .td files > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118>. From > the > answers, it seems like confusion can arise from the fact flags don't need to > be listed explicitly if they are inferred from patterns. Hal Finkel suggests > auditing the generated tablegen output directly. > > * Jon Pry has posted an RFC suggesting to change the datalayout for the Radeon > R600 backend > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69130>. > The problem is that the r600 datalayout description currently claims native > integer widths of 32 and 64 bit, but support for 64 bit arithmetic is actually > limited to getelementptr-like load/store operations (although this point is > debated in replies to the thread). The patch proposes to simply claim native > 32 bit integer width only, though alternative solutions are proposed in thread > responses. > > * Andrew Trick outlines an algorithm to estimate cycles taken on an > out-of-order core > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69145> > > * Build bot fatigue > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69103> is causing > problems. In short the build bots are sending too many messages, and slow > servers keep on sending messages for issues that were fixed already resulting > in a low signal to noise ratio. There was a suggestion to move to the phased > builder infrastructure as used by Apple. There were additional complaints from > Alp about large numbers of emails from ARM buildbots about errors such as > out > of disk <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200>. > Renato Golin responds explaining that due to the lack of commercial ARM > server > hardware they have to rely on development boards or consumer laptops, which > may not be the most reliable under heavy load. > > * Snehasish Kumar asks about using DependenceAnalysis to find both > loop-independent and loop-carried dependences, receiving some useful > responses. > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094> > > * David Fang posts a summary of the current status of the PowerPC-Darwin > ports > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69196>. An > extensively detailed status page is also available at > <http://www.csl.cornell.edu/~fang/sw/llvm/> > > * Swarup Kumar Sahoo points to the current giri code > <https://github.com/liuml07/giri> in response to a question about how to > trace > every value and address used by a program. > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69150> > > * Tim Northover provides a straight forward overview of what to do in order to > disable loop unrolling and function inlining, and where the source to the > relevant passes can be found > <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69213> > > * Michael Schlottke asks for advice about LibTools vs LibClang+Python for some > C++ refactoring tasks. > <http://article.gmane.org/gmane.comp.compilers.clang.devel/34050> The > mailing > list is overwhelmingly in favour of using LibTooling, though it does have the > downside that nobody has produced Python bindings to it yet. > > ## LLVM commits > > Warning: this is an opinionated, unscientific highlighting of certain LLVM > commits. I may have missed your favourite change - apologies. > > * An initial ASM parser was added to the SPARC backend > <http://llvm-reviews.chandlerc.com/rL198484>. The backend also learned to > handle atomics loads/stores <http://llvm-reviews.chandlerc.com/rL198286>. > > * Various AVX512 (currently only available in Xeon Phi CPUs) intrinsics were > added <http://llvm-reviews.chandlerc.com/rL198277>, > <http://llvm-reviews.chandlerc.com/rL198557> > > * ARM: For compatibility with GNU as, aliases for old (deprecated) FP > mnemonics were added <http://llvm-reviews.chandlerc.com/rL198172>. > Additionally, softvfp was added to the list of supported FPU names > <http://llvm-reviews.chandlerc.com/rL198313> > > * The LLVM mangler, used to determin the symbol name of a GlobalValue no > longer requires linking with Target. This means the DataLayout now contains a > specification for the name mangling behaviour. > <http://llvm-reviews.chandlerc.com/rL198438> > > * tryInstructionSplit() has been made less aggressive > <http://llvm-reviews.chandlerc.com/rL198369> > > * In the world of tablegen, a bug with the use of multiclass parameters was > fixed <http://llvm-reviews.chandlerc.com/rL198348> > > * A confusion between `Value*` identify and 'value' equivalence was corrected > in BasicAA <http://llvm-reviews.chandlerc.com/rL198290> > > ## Clang commits > > * RecursiveASTVisitor and DataRecursiveASTVisitor learned to visit attributes > <http://llvm-reviews.chandlerc.com/rL198224>, > <http://llvm-reviews.chandlerc.com/rL198249> > > * ExpectAndConsume will diagnose more errors automatically > <http://llvm-reviews.chandlerc.com/rL198270> > > * The formatter gained an option to avoid splitting certain sorts of comments > which have special meaning (e.g. pragmas) across multiple lines > <http://llvm-reviews.chandlerc.com/rL198310>. It can also format short enums > on to a single line <http://llvm-reviews.chandlerc.com/rL198558> > > * The VBTableBuilder class was moved from CodeGen to AST with the long-term > goal of using it to compute virtual fuction table names > <http://llvm-reviews.chandlerc.com/rL198380> > > * CreateAnalysisConsumer is added to the static analyzer's public interface as > a way to get at its ASTConsumer. <http://llvm- > reviews.chandlerc.com/rL198426> > > * Virtual base class table mangling is now more compatible with MSVC202+ > <http://llvm-reviews.chandlerc.com/rL198462> > > * The IdempotentOperations checker was killed as it has various known issues > and nobody has come forwards to fix them. > <http://llvm-reviews.chandlerc.com/rL198476> > > * `dump()` function definitions are now only marked as used in debug builds. > This will enable more stripping of dead code in release builds resulting in > smaller filesize. <http://llvm-reviews.chandlerc.com/rL198489> > > * Previously, clang could be tortured by providing a K and R style function > declaration with a missing semicolon, e.g. `void knrNoSemi(i) int i { }` which > would result in a long stream of errors covering the rest of the input file. > It now recognises this error and presents a single error > <http://llvm-reviews.chandlerc.com/rL198540>. > > ## Other project commits > > * Building libclc with LLVM 3.5 was fixed > <http://llvm-reviews.chandlerc.com/rL198167> > > * In libcxx, the clz/ctz family of functions are now implemented for when > building with Visual C++ on Win32 or Win64. > <http://llvm-reviews.chandlerc.com/rL198481> > > * The PollyCananicalizePass was introduced. This is a ModulePass that > schedules the Polly canonicalization passes. > <http://llvm-reviews.chandlerc.com/rL198376> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 6 January 2014 22:49, Alex Bradbury <asb at asbradbury.org> wrote:> LLVM Weekly - #1, Jan 6th 2014 > =============================> > Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter (published > every Monday) covering developments in LLVM, Clang, and related projects.Thank you to all those who have responded publicly or privately with comments and encouragement. When subscribing some received duplicated confirmation emails, I have fixed that issue. I've also cleaned up the html version of the issue (it was really written to target plaintext readability). Does anyone have strong feelings against continuing to post these summaries to the llvmdev mailing list? Alex
On Jan 7, 2014, at 4:13 AM, Alex Bradbury <asb at asbradbury.org> wrote:> On 6 January 2014 22:49, Alex Bradbury <asb at asbradbury.org> wrote: >> LLVM Weekly - #1, Jan 6th 2014 >> =============================>> >> Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter (published >> every Monday) covering developments in LLVM, Clang, and related projects. > > Thank you to all those who have responded publicly or privately with > comments and encouragement. When subscribing some received duplicated > confirmation emails, I have fixed that issue. I've also cleaned up the > html version of the issue (it was really written to target plaintext > readability). > > Does anyone have strong feelings against continuing to post these > summaries to the llvmdev mailing list?This is definitely on topic (and totally awesome, btw!) for llvmdev. Please do send it here! -Chris