Geoff Shannon | 21 Oct 19:42 2014

Updating Kaleidoscope tutorial

Hi there,

I've been working through the tutorial on using LLVM to implement a small language (, and I noticed that the code in the tutorial is a bit out of sync with LLVM 3.5.

I managed to get the code working, and it appears to even be working correctly.  I'd like to help correct the tutorial so that other people can also benefit from the pain and heartache I went through figuring out what to change.

What would be the best way for me to do that?  I asked on the IRC channel and someone suggested that I send a patch to the mailing list.  But I'm curious if the patch should be of the html of the tutorial page, or of something else.


Nothing is ever easy.
LLVM Developers mailing list
LLVMdev <at>
Kristof Beyls | 21 Oct 15:30 2014

Performance tracking and benchmarking infrastructure BoF

As preparation for the performance tracking and benchmarking infrastructure BoF next week at the dev meeting, Chad, Chris, Tobias, Renato and myself have started brainstorming and trying to somewhat organize the topics we feel should be discussed.


We've got a google docs document with an outline of what we think should be discussed. We very much welcome comments, suggestions and feedback on it before the BoF, so that we can make the best possible use of the allocated BoF time next week.


At the moment, the top-level topics we'd like to discuss are:

* Producing low-noise performance numbers

* Easily interpreting performance numbers

* Acting on Regressions

* Enhanced data collection

* Getting a stable and high-quality warning system

* Making a larger part of the community care

* Guidelines for setting up a performance tracking bot

* Making performance tracking server more stable and easier to administer


More details are in the google docs document, accessible through the link below. Feel free to add comments directly to the google docs

document, or by replying to this email.





LLVM Developers mailing list
LLVMdev <at>
Chris Bieneman | 20 Oct 21:46 2014

[RFC] New ToolsSupport library for stuff that only tools need

There are some pieces of functionality in LLVM today, that make sense for tools like llc, opt, clang, but
they aren't relevant for embedded uses like LLVM in the JavaScript JIT. One example of this type of
functionality is the signal handlers.

I'd like to propose migrating content that is specifically designed for tools into a new ToolsSupport
library. My initial candidates for the new library would be; anything guarded by
ENABLE_CRASH_OVERRIDES, and any functionality specific to tools (i.e. ToolOutputFile and eventually
command line parsing— once it can be factored out).

The primary goal of this is to make it easy for uses of LLVM that aren't command line tools to not include
functionality that isn't required for that use case.


LLVM Developers mailing list
LLVMdev <at>
Shankar Easwaran | 20 Oct 14:25 2014

[lld][ELF] obj2yaml vs normalized input files (similar to macho)


After looking at the Normalized Readers in mach-o, I feel it would be 
nice if the Gnu flavor to adopt this design what mach-o did in addition 
to using obj2yaml.

Its so much easier to test in the context of lld with normalized 
readers, IMO.

Opinions ?


Shankar Easwaran


Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
JinGu Kang | 20 Oct 13:37 2014

Question about "VectorLegalizer::ExpandUINT_TO_FLOAT".

Hi all,

I have a question about "VectorLegalizer::ExpandUINT_TO_FLOAT" function.

I have code snippet on DAG as follows.

0x7a351a8: v4i32 = insert_vector_elt  0x7a350a0,  0x7a34f00, 0x7a34198 
[ORD=7] [ID=-3]
0x7a353b8: v4f16 = uint_to_fp  0x7a351a8 [ORD=8] [ID=-3]

Can "VectorLegalizer::ExpandUINT_TO_FLOAT" function handle above case? 
The problem I have faced is "SDValue TWOHW" gets "Infinity" number 
because it is overflow and then "SDValue fHI" is set to "Nan" from fmul. 
Is it correct? If I miss something, please let me know.

JinGu Kang
Alex Bradbury | 20 Oct 13:29 2014

LLVM Weekly - #42, Oct 20th 2014

LLVM Weekly - #42, Oct 20th 2014

If you prefer, you can read a HTML version of this email at

Welcome to the forty-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
Subscribe to future issues at <> and pass it on to anyone
else you think may be interested. Please send any tips or feedback to
<asb <at>>, or  <at> llvmweekly or  <at> asbradbury on Twitter.

If you're local to London, you may be interested to know that I'll be talking
about [lowRISC]( at the [Open Source Hardware User
Group on Thursday](

## News and articles from around the web

ELLCC, the LLVM-based cross-compilation toolchain [now has pre-built binaries
for all LLVM

Eli Bendersky's repository of examples for using LLVM and Clang as libraries
and for building new passes aren't new, but they are incredibly useful for
newcomers to LLVM/Clang and I haven't featured them before. If you want to
build something using LLVM or Clang, the [llvm-clang-samples
repos]( is one of the best places
to start.

## On the mailing lists

* If you enjoy bikeshedding, I have the perfect thread for you. [Should LLVM
change its naming convention for
There actually seems to be a lot of consensus that the current approach of
using capitalized variable names is weird.

* Richard Smith has proposed [switching the default C language mode from gnu99
to gnu11](
GNU trunk has just switched from gnu89 by default to gnu11. There seems to be
almost universal support for gnu11 by default.

* Junio Cezar writes to the mailing list [to share his experiments on time
taken in various LLVM
passes]( His
webpage has [plots of time taken in each stage for csmith-generated
programs]( Hal Finkel had some
[suggestions on improving the

* Bill Wendling is [stepping down as LLVM release
manager]( He
nominated Tom Stellard and Hans Wennborg as his replacements, who have been
accepted by unanimous agreement.

* Chandler Carruth [suggests making DataLayout

## LLVM commits

* Go LLVM bindings have been committed.

* Invoking patchpoint intrinsics is now supported.

* LLVM gained a workaround for a Cortex-A53 erratum.

* Basic support for ARM Cortex-A17 was added.

* The C API has been extended with the LLVMWriteBitcodeToMemoryBuffer
function. [r219643](

* NumOperands has been moved from User to Value. On 64-bit host architectures
this reduces `sizeof(User)` and subclasses by 8.

* The LLVMParseCommandLineOptions was added to the C API.

## Clang commits

* Constant expressions can now be used in pragma loop hints.

* The libclang API gained a function to retrieve the storage class of a
declaration. [r219809](

* With the `-fsanitize-address-field-padding` flag, Clang can insert poisoned
paddings between fields in C++ classes to allow AddressSanitizer to find
intra-object overflow bugs. [r219961](

## Other project commits

* lldb now supports a gdb-style batch mode.
Renato Golin | 20 Oct 12:53 2014

Lib C++ buildbot problem


I'm trying to set up a libc++ buildbot on ARM and I found an
inconsistency which I'm not sure how to fix.

I got a build error like this: undefined reference to `_Unwind_GetGR'

Since I expected that the symbol would be provided by that library, I
searched the CMake on libc++abi and found this:

option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." OFF)

But on the Libc++AndAbiBuilder, there's no way to set the CMake
argument (or is there?):

def getLibcxxAndAbiBuilder(f=None, env={}, additional_features=set()):

"additional_features" seem to imply only lit test args, not anything else.


Tyler Denniston | 19 Oct 17:32 2014

SSA for memory objects


I'm looking to learn more about what is available for memory  
versioning or inducing some kind of SSA for memory objects. I found  
this page:

Which says: "[LLVM] does not require (or permit) memory objects to be  
in SSA form.... In LLVM, instead of encoding dataflow analysis of  
memory into the LLVM IR, it is handled with Analysis Passes which are  
computed on demand."

However, there is no mention of which analyses provide this. I also  
haven't been able to turn up much in the way of documentation or  
examples, so I'm grateful for any additional pointers.


Chandler Carruth | 19 Oct 10:22 2014

RFC: Are we ready to completely move away from the optionality of a DataLayout?

I've just wasted a day chasing my tail because of subtleties introduced to handle the optionality of the DataLayout. I would like to never do this again. =]

We now have this attached to the Module with just a flimsy faked-up pass to keep APIs consistent. So, is there any problem with beginning down the path of:

1) Synthesizing a "default" boring DataLayout for all modules that don't specify one.
2) Changing the APIs to make it clear that this can never be missing and is always available.
3) Start ripping out all of the complexity in the compiler dealing with this.

If there isn't, I'm willing to do some of the leg work here.
LLVM Developers mailing list
LLVMdev <at>
Nitin Mukesh Tiwari | 18 Oct 23:13 2014

Query regarding backend of Clang

Dear LLVM Team
I am looking for a llvm beasede compiler nad dont want to use GCC or any other based compiler. I have installed the clang++ and LLVM by following instruction from page

I want to use LLVM based compiler for making some changes in ANSI C compiler for a project. My goal is to use LLVM compiler so that compilation process becomes fast.

Could please tell me that do I need to use some other compiler or by following the above mentioned instruction I have installed LLVM based compiler. As Clang++ is just a front end and uses other compiler in backend. So is it a LLVM based compiler or GCC based compiler?
And is ther any way that I can check which compiler Clang++ is using?

Thanks and Regards

LLVM Developers mailing list
LLVMdev <at>
Liang Wang | 18 Oct 02:21 2014

Dereferencing NULL pointer in IndVarSimplify.cpp?


Here is the code in IndVarSimplify.cpp.

    SmallVector<WeakVH, 16> DeadInsts;

  while (!DeadInsts.empty())
    if (Instruction *Inst =
      RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI);

Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL
pointer, the expression, &*DeadInsts.pop_back_val(), could be &*NULL.
Then NULL pointer is dereferenced here.

I wrote a small test case and it works just fine. But is this a
well-defined behavior in the standard?