[LLVMdev] LLVM Weekly - #1, Jan 6th 2014

[Eric Christopher]

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>