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

[Greg Fitzgerald]

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
>