[LLVMdev] LLVM Weekly - #6, Feb 10th 2014
Alex Bradbury
asb at asbradbury.org
Mon Feb 10 06:10:19 PST 2014
LLVM Weekly - #6, Feb 10th 2014
===============================
If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/6>
Welcome to the sixth issue of LLVM Weekly, a weekly newsletter (published
every Monday) covering developments in LLVM, Clang, and related projects.
LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org).
Subscribe to future issues at <http://llvmweekly.org> and 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. I've been
keeping the [@llvmweekly Twitter account](https://twitter.com/llvmweekly)
updated throughout the week, so follow that if you want more frequent news
updates.
## News and articles from around the web
Alexi Starovoitov has [published an LLVM
backend](https://lkml.org/lkml/2014/2/5/743) targeting an extended version of
the Linux Kernel's BPF. An example of the sort of program that might be
compiled and run via BPF can be found
[here](http://article.gmane.org/gmane.linux.kernel/1605783).
There is now under a week to go to submit proposals for presentations,
tutorials, posters, etc for the upcoming [EuroLLVM
2014](http://llvm.org/devmtg/2014-04/). Get writing!
LWN's coverage of the recent discussion about LLVM and its licensing on the
GCC mailing list is [now available](http://lwn.net/Articles/582697/) to
non-subscribers.
Renato Golin [posted to the GCC mailing
list](http://gcc.gnu.org/ml/gcc/2014-02/msg00093.html) suggesting there be
more collaboration where possible on issues such as standardisation of command
line interfaces, language extensions, or just general technical discussion.I
know a mailing list GCC developers who want to keep abreast of LLVM/Clang
developments should subscribe to...
Phoronix has [published a
benchmark](http://www.phoronix.com/scan.php?page=article&item=intel_haswell_gcclang34&num=1)
comparing GCC 4.8.2, a GCC 4.9 snapshot and Clang 3.4 on an Intel Core i5-4670
system.
## On the mailing lists
* Sony Computer Entertainment America are [looking for an
intern](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70232) for
their compiler engineering team.
* Venkatraman Govindaraju reports that [Clang can now self host on
Linux/sparc64 and
FreeBSD/sparc64](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70033).
* Paul Vario [asks for more information on the algorithm used in
RegionInfo](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70193),
noting that the algorithm implemented seems substantially different to the one
referenced in the
[paper](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.5126) in
the header's comment. The original author of that code, Tobias Grosser follows
up with an [explanation for differences from that
paper](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70198).
* Gordon Keiser helpfully reminds us that [clang will happily take LLVM
bitcode as
input](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70179).
* Stephen Kelly, an upstream CMake developer [dropped
by](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70022) to offer
advice on LLVM's current CMake usage and learn what problems with CMake the
project is facing. A number of responses are interested in the ability to use
CMake to build multiple LLVM subprojects at once, or to build clang against an
installed LLVM tree.
* Last week's [RFC questioning the use of
BlockFrequency](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70027)
has now had a number of followups. I won't summarise here for fear of
mischaracterising people, but do take a look if the issue interests you.
* Tom Stellard is [looking for bugfix
patches](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70210) that
should be merged in to a future 3.4.1 release.
* Renato Goling started a [discussion about unwind and exception handling
behaviour](http://article.gmane.org/gmane.comp.compilers.llvm.devel/70186) in
LLVM/Clang, listing four problems he sees with the code as-is.
* Vassil Vassilev asks whether anyone has implemented a [copy and paste
detector for Clang's static
analyzer](http://article.gmane.org/gmane.comp.compilers.clang.devel/34882).
Nick Lewycky [shares his
implementation](http://article.gmane.org/gmane.comp.compilers.clang.devel/34921)
of something in that direction.
* Ben Langmuir posted an [RFC on a virtual filesystem for
clang](http://article.gmane.org/gmane.comp.compilers.clang.devel/34941). This
aims to "allow a build system to provide a file/directory layout to clang
without having to construct it 'for real' on disk".
## LLVM commits
* The x86 backend was slightly simplified by moving some matching for x86 bit
manipulation instructions from X86ISelLowering.cpp to X86InstrInfo.td. I
mention this commit mainly as it's a useful reference for those of you working
on LLVM backend code. [r200824](http://llvm-reviews.chandlerc.com/rL200824).
* The register allocator gained a new 'last chance recoloring mechanism'.
Sadly the commit message doesn't include any data of how this improves
register allocation for a given codebase.
[r200883](http://llvm-reviews.chandlerc.com/rL200883).
* The old SmallPtrSetImpl was renamed to SmallPtrSetImplBase, and a new
SmallPtrSetImpl was introduced. This new SmallPtrSetImpl doesn't require a
specific set size to be specified in its templated parameter.
[r200688](http://llvm-reviews.chandlerc.com/rL200688).
* A whole bunch of code was added to CodeGenPrepare which attempts to move
sign extensions away from loads in order to increase the chance that the
address computation can be folded in to the load on architectures like x86
with complex addressing modes.
[r200947](http://llvm-reviews.chandlerc.com/rL200947).
* `strchr(p, 0)` is now simplified to `p + strlen(p)`.
[r200736](http://llvm-reviews.chandlerc.com/rL200736).
* Information on handling minor ('dot') releases was added to the
HowToReleaseLLVM documentation.
[r200772](http://llvm-reviews.chandlerc.com/rL200772).
* The MIPS assembler learned to understand `%hi(sym1 - sym2)` and `%hi(sym1 -
sym2)` expressions. [r200783](http://llvm-reviews.chandlerc.com/rL200783).
* Mips gained a NaCl target.
[r200855](http://llvm-reviews.chandlerc.com/rL200855).
* LLVM now assumes the assembler supports the `.loc` directive for specifying
debug line numbers. [r200862](http://llvm-reviews.chandlerc.com/rL200862).
* The inliner was modified to consider the cold attribute on a function when
deciding whether to inline.
[r200886](http://llvm-reviews.chandlerc.com/rL200886). A later commit set the
inlinecold-threshold to the same as the inline-threshold so that current
inlining behaviour is maintained for now.
[r200898](http://llvm-reviews.chandlerc.com/rL200898).
* Initial implementation for a lazy call graph analysis pass (for use with the
upcoming new pass manager) was committed.
[r200903](http://llvm-reviews.chandlerc.com/rL200903).
* The allowsUnalignedMemoryAccess function in TargetLowering now takes an
address space argument. This was added for architectures like the R600 where
different address spaces have different alignment requirements.
[r200887](http://llvm-reviews.chandlerc.com/rL200887).
## Clang commits
* More support was MS ABI-compatible mangling was added.
[r200857](http://llvm-reviews.chandlerc.com/rL200857).
* The behaviour suggested by the C++ Defect Report
[329](http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#329) was
implemented. [r200673](http://llvm-reviews.chandlerc.com/rL200673).
* The ARM target gained support for crypto intrinsics defined in `arm_neon.h`.
[r200708](http://llvm-reviews.chandlerc.com/rL200708).
* The forRangeStmt AST matcher gained a handy hasLoopVariable sub-matcher.
[r200850](http://llvm-reviews.chandlerc.com/rL200850).
* The -verify-pch CC1 option is now supported.
[r200884](http://llvm-reviews.chandlerc.com/rL200884).
* The -fhiding-week-vtables CC1 option has been removed.
[r201011](http://llvm-reviews.chandlerc.com/rL201011).
* LLVM's new diagnostic system is now wired into clang's diagnostic system.
[r200931](http://llvm-reviews.chandlerc.com/rL200931).
## Other project commits
* The address sanitizer gained two functions that would allow implementation
of C++ garbage collection to work with its fake stack.
[r200908](http://llvm-reviews.chandlerc.com/rL200908).
* In lldb, the the Mac OS X SystemRuntime plugin now uses the
libBacktraceRecording library.
[r200822](http://llvm-reviews.chandlerc.com/rL200822).
More information about the llvm-dev
mailing list