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

Mon Jan 6 19:14:29 PST 2014

Thanks, Alex.
It is very useful.

2014/1/7 Greg Fitzgerald <garious at gmail.com>

> 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
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
Shining(史宁)
Changchun, Jilin, China
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140107/72563437/attachment.html>