[llvm-dev] LLVM Weekly - #133, Jul 18th 2016
Alex Bradbury via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 18 07:23:51 PDT 2016
LLVM Weekly - #133, Jul 18th 2016
=================================
If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/133>.
Welcome to the one hundred and thirty-third 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'm now back in the UK after being in Boston for the [fourth RISC-V
workshop](https://riscv.org/2016/07/4th-risc-v-workshop-final-agenda/) along
with my colleagues on the lowRISC project to produce a complete open-source
SoC. You may be interested in my [notes from talks at the
event](http://www.lowrisc.org/blog/2016/07/notes-from-the-fourth-risc-v-workshop/).
## News and articles from around the web
The LLVM Foundation is [advertising for applicants to become a board
member](http://llvm.org/foundation/board-application.html). If you are
interested in becoming a board member, note this current application round
closes on July 27th.
Sanjoy Das has written a blog post on [inter-procedural optimisation and
derefinement](http://www.playingwithpointers.com/ipo-and-derefinement.html).
## On the mailing lists
* The RFC on [handling strong GC references in
LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102161.html) by
Sanjoy Das has seen a flood of responses this week. A number of respondents
question whether a new type is needed. Sanjoy has summarised the [suggested
options](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102326.html).
* Sean Silva suggests the new pass manager [should learn about inter-analysis
depencies](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102224.html).
Sean followed up with a [more detailed analysis of the
problem](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102297.html) which
Chandler Carruth [responded
to](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102339.html).
* Gor Nishanov has shared [version 2 of his coroutine
proposal](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102133.html).
Additionally, he's written an [RFC on coroutine optimisation
passes](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102337.html).
* Alex Denisov is interested in establishing an [LLVM Social event in
Berlin](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102280.html) and
invites anyone else interested to get in touch. It seems there was enough
interest to [set up a Meetup
group](http://www.meetup.com/LLVM-Social-Berlin/).
* Justin Bogner has shared a plea to [stop using target-specific intrinsics in
generic code](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102317.html),
along with a patch that starts to improve things. All responses are strongly
in favour of this direction.
* Naoki Shibata has, along with Hal Finkel, [proposed the inclusion of the
SLEEF vectorized math
library](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102254.html). As
Hal [notes](http://lists.llvm.org/pipermail/llvm-dev/2016-July/102350.html),
Intel have been contributing support for their SVML library, but a solution is
still needed that is easily portable to other architectures.
## LLVM commits
* GVNHoist, a code hoisting pass based on global value numbering has been
added. This hoists duplicated computations with the goal of reducing the size
of functions before inline heuristics so as to reduce the total cost of
function inlining. [r275561](http://reviews.llvm.org/rL275561).
* The first patch implementing 'hotness' attributes has landed. Currently, for
missed optimisation remarks for loop distribution it will indicate the hotness
(the multiplication of the block frequency with the function entry count).
[r275583](http://reviews.llvm.org/rL275583).
* A new LazyBFI (lazy block frequency info) pass was added. With this pass,
block frequencies are computed only when the results are explicitly requested
by the analysis client. [r275250](http://reviews.llvm.org/rL275250).
* LLVM's ADT library gained an `LLVM_MARK_AS_BITMASK_ENUM` define, which can
be used to enable bitwise operations on enums without a `static_cast`.
[r275292](http://reviews.llvm.org/rL275292).
* llvm-cov learnt to use multiple threads to speed up report generation.
[r275321](http://reviews.llvm.org/rL275321).
* The XRay function tracing framework is starting to land, with the first
patch adding support for entry and exit sleds for functions.
[r275367](http://reviews.llvm.org/rL275367).
* An improved algorithm is now used for selecting a base constant in constant
hoisting. [r275382](http://reviews.llvm.org/rL275382).
* Various SelectionDAG methods (getLoad, getStore, and more) have been
modified to take a single flags argument (bitset) rather than multiple
booleans. [r275592](http://reviews.llvm.org/rL275592).
* CFLAA gained an initial 'CFLAnders' implementation.
[r275602](http://reviews.llvm.org/rL275602).
## Clang commits
* `-fxray-instrument` and `-fxray-instruction-threshold` were added to control
XRay function tracing. [r275330](http://reviews.llvm.org/rL275330).
* Implementation of C++17's init-statement for `if` and `switch` has been
completed now semantic analysis and code generation has been added.
[r275350](http://reviews.llvm.org/rL275350).
* The new `-fno-pch-timestamp` option will disable inclusion of timestamps in
a PCH file, and is intended to allow distributed build systems to use PCH.
[r275267](http://reviews.llvm.org/rL275267).
* clang-rename gained some documentation.
[r275388](http://reviews.llvm.org/rL275388).
## Other project commits
* LLD's COFF linker no longer relies on lib.exe to generate an empty import
library. [r275242](http://reviews.llvm.org/rL275242).
* libcxxabi gained a top-level CMake option to use compiler-rt instead of
libgcc. [r275505](http://reviews.llvm.org/rL275505).
More information about the llvm-dev
mailing list