[LLVMdev] LLVM Weekly - #52, Dec 29th 2014
Philip Reames
listmail at philipreames.com
Mon Dec 29 10:43:42 PST 2014
Agreed. Thanks for putting this together.
Philip
On 12/29/2014 07:42 AM, Eli Bendersky wrote:
> Thanks for keeping running this, Alex. LLVM weekly is a great resource
> for those weeks when you just don't have time to go through the full
> mailing list archives.
>
> Eli
>
> On Mon, Dec 29, 2014 at 2:02 AM, Alex Bradbury <asb at asbradbury.org
> <mailto:asb at asbradbury.org>> wrote:
>
> LLVM Weekly - #52, Dec 29th 2014
> ===============================
>
> If you prefer, you can read a HTML version of this email at
> <http://llvmweekly.org/issue/52>.
>
> Welcome to the fifty-second 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 <mailto:asb at asbradbury.org>>, or
> @llvmweekly or @asbradbury on Twitter.
>
> This issue marks the end of one full year of LLVM Weekly. It's a
> little
> shorter than usual as the frenetic pace of LLVM/Clang development
> has slowed
> over the holiday period. Surprising even to me is that we managed
> to make it
> all 52 weeks with an issue every Monday as promised. This requires a
> non-trivial amount of time each week (2-3+ hours), but I am
> intending to keep
> it going into 2015. I'd like to give a big thank you to everyone
> who's said hi
> at a conference, sent in corrections or tips on content, or just
> sent a random
> thank you. It's been very helpful in motivation. I don't currently
> intend to
> change anything about the structure or content of each issue for
> next year,
> but if you have any ideas then please let me know.
>
> I can't make it to 31C3 due to the awkward timing of the event,
> but do let me
> know if there are any LLVM/Clang related talks worth sharing.
> There was a
> [talk about Code Pointer
> Integrity](https://events.ccc.de/congress/2014/Fahrplan/events/6050.html)
> which has previously been covered in LLVM Weekly and is working
> towards
> upstreaming. The video is
> [here](http://streaming.media.ccc.de/relive/6050).
> If you're interested in [lowRISC](http://www.lowrisc.org) and at
> 31C3, Bunnie
> is leading a
> [discussion about
> it](https://events.ccc.de/congress/2014/wiki/Session:LowRISC_Discussion)
> at 2pm on Monday (today).
>
>
> ## News and articles from around the web
>
> There doesn't seem to have been any LLVM or Clang related news
> over the past
> week. Everyone seems to be busy with non-LLVM related activities
> over the
> christmas break. If you're looking for a job though, Codeplay tell
> me they
> have two vancancies: one for a [debugger
> engineer](https://www.codeplay.com/company/jobs/view.html?uid=15#.VJft5P84JA)
> and another for a
> [compiler
> engineer](https://www.codeplay.com/company/jobs/view.html?uid=12#.VJft7_84JA).
>
>
> ## On the mailing lists
>
> * David Li has shared some [early info on Google's plans for
> LTO](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80167).
> He
> describes the concept of 'peak optimization performance' and some
> of the
> objectives of the new design. This includes the ability to handle
> programs 10x
> or 100x the size of Firefox. We can expect more information in
> 2015, maybe as
> early as January.
>
> * The discussion on possible approaches to reducing the size of
> libLLVM has
> continued. Chris Bieneman has [shared some more size
> stats](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80096).
> These
> gains come from removing unused intrinsics. Chandler Carruth has
> followed up
> with a pleasingly thought-provoking argument on a different approach:
> [target-specific intrinsics shouldn't exist in the LLVM front or
> middle-end](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80130).
> He describes the obvious issues with this, with the most fiddly
> probably being
> instruction selection converting appropriate IR to the right
> target-specific
> functionality.
>
>
> ## LLVM commits
>
> * The SROA (scalar replacement of aggregates) pass has seen some
> refactoring
> to, in the future, allow for more intelligent rewriting.
> [r224742](http://reviews.llvm.org/rL224742),
> [r224798](http://reviews.llvm.org/rL224798).
>
> * The masked load and store intrinsics have been documented.
> [r224832](http://reviews.llvm.org/rL224832).
>
> * CodeGenPrepare learned to speculate calls to llvm.cttz/ctlz (count
> trailing/leading zeroes) if
> `isCheapToSpeculateCtlz/isCheapToSpeculatCttz` in
> TargetLowering return true.
> [r224899](http://reviews.llvm.org/rL224899).
>
>
> ## Clang commits
>
> * The Clang internals manual has been extended with stub sections
> on Parse,
> Sema, and CodeGen. [r224894](http://reviews.llvm.org/rL224894).
>
>
> ## Other project commits
>
> * The libcxx LIT test-suite has seen a number of new configuration
> options.
> Even better, these are [now
> documented](http://libcxx.llvm.org/lit_usage.html).
> [r224728](http://reviews.llvm.org/rL224728).
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141229/7a69d3a3/attachment.html>
More information about the llvm-dev
mailing list