Chad Rosier | 2 Aug 01:04 2014

Dev Meeting BOF: Performance Tracking

I'm curious to know if anyone is interested in tracking performance
(compile-time and/or execution-time) from a community perspective?  This
is a much loftier goal then just supporting build bots.  If so, I'd be
happy to propose a BOF at the upcoming Dev Meeting.

Chad Rosier | 2 Aug 01:04 2014

Dev Meeting BOF: Performance Tracking

I'm curious to know if anyone is interested in tracking performance
(compile-time and/or execution-time) from a community perspective?  This
is a much loftier goal then just supporting build bots.  If so, I'd be
happy to propose a BOF at the upcoming Dev Meeting.

Jeff Kuskin | 1 Aug 22:23 2014

BR_CC questions

I am implementing a new backend and am pretty sure I don't quite understand "the way" one is supposed to
implement conditional branches.

My target CPU natively supports a conditional branch instruction that accepts a condition to test (equal,
less than, etc.), two operands (two registers, or one register and one immediate), and finally a target PC
to branch to if the comparison succeeds.

Great -- that all seems to mesh directly with the ISD::BR_CC opcode.

However... I can't seem to use 'brcc' or 'br_cc' in the .td file.  Neither is recognized as a valid
keyword.  I can use 'brcond', but given the capabilities of the CPU I'm targeting, it seems better to
implement BR_CC directly and do setOperationAction(ISD::BRCOND, MVT::Other, Expand) to get BRCOND
nodes expanded into BR_CC.  Correct?

I tried implementing comparison operations and 'brcond' in the .td file, but that yields assembly code
that does a comparison instruction followed by a branch instruction, when the underlying CPU supports
folding the comparison into the branch.

Is it in fact possible to use BR_CC directly in the TD file?  If so, how?  In particular, what pattern would
I use?  If not, what is the recommended way to proceed (at a high level) when the target CPU supports
conditional branches as I outlined above?

Thanks for any help!
Tobias Grosser | 1 Aug 22:05 2014

Recent compile time performance regressions


I was just browsing my LNT performance builder and it seems within the 
last month we managed to increase compile time from 37 to 47 seconds for 
the bullet benchmark:

A similar pattern can be seen for MallocBench/gs/gs where we go from 5.3
to 7.4 seconds.

One contributing patch seems to be the following one (surprisingly):

Author: Chandler Carruth <chandlerc <at>>
Date:   Fri Jun 27 15:13:01 2014 +0000

     Re-apply r211287: Remove support for LLVM runtime multi-threading.

     I'll fix the problems in libclang and other projects in ways that
     don't require <mutex> until we sort out the cygwin situation.

     git-svn-id: <at> 211900

I also looked at the earlier performance regressions, but could not find 
any obvious commits that could have caused these regressions.

This is mostly a drive by observation, but maybe someone is motivated to 
investigate this further.
(Continue reading)

Nadav Rotem | 1 Aug 20:01 2014

[ADVERTISEMENT] Open positions in Apple's Swift compiler team

** NOTE: This is a compiler job announcement. **

The Apple Swift performance team is looking for exceptional engineers to work on LLVM and the Swift programming language:

This open position is for engineers who want to work as part of the Swift team on optimizing the performance of the Swift compiler. This job involves working on the swift optimizer as well as working on improving LLVM, which is a central technology in the Swift language. 

To apply please email me your resume in PDF and include a brief statement about yourself and how you see a potential fit for the team (e.g., interests, background, etc.). 

Ideal candidates will have skills in the following areas:

- A passion for optimizing code!
- Strong C++ coding skills.
- Familiarity with LLVM or Clang a plus, but not required.
- Diverse exposure to different programming languages.
- Strong skills in low-level performance optimization.

Please forward to anyone who may be interested.


LLVM Developers mailing list
LLVMdev <at>
Itaru Kitayama | 31 Jul 15:20 2014

LLVM Testing


Is this the right mailing list to discuss LLVM testing issues?


Prakash Premkumar | 1 Aug 14:42 2014

LLVM Basic Program Compilation

I am just getting started with llvm.

Here's code I am trying to compile:

#include <stdio.h> #include "llvm/IR/LLVMContext.h" #include "llvm/IR/Module.h" #include "llvm/IR/IRBuilder.h" int main() { llvm::LLVMContext& context = llvm::getGlobalContext(); llvm::Module* module = new llvm::Module("top", context); llvm::IRBuilder<> builder(context); module->dump( ); }

when i compile with :

llvm-g++ try.cpp -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS `llvm-config --cxxflags --ldflags --libs`

I get the a.out file. No worries.

But, I am interested in getting the LLVM IR file.So, I compiled with

llvm-g++ try.cpp -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -S -emit-llvm lli try.s

I get an error saying

LLVM ERROR: Program used external function '_ZN4llvm16getGlobalContextEv' which could not be resolved!

The command :

llvm-g++ try.cpp -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS `llvm-config --cxxflags --ldflags --libs` -S -emit-llvm

leaves me with several warnings and when i execute the resultant .s file with lli , I get the same error as before.

Thanks a lot for your help

Thank you,

Prakash Premkumar

LLVM Developers mailing list
LLVMdev <at>
Jonas Maebe | 1 Aug 14:27 2014

Create "appending" section that can be partially dead stripped


Is there a way in llvm IR to emit multiple data elements within a  
single compilation unit that
a) are guaranteed to appear sequentially in the final binary (in the  
order they appear in the llvm IR), and
b) will be removed on an individual basis by the optimizers and/or  
linker in case they are not referenced from anywhere

Defining them as "appending" puts them all into a single section  
definition, even when compiling with -fdata-sections, so as soon as  
one of the symbols in that section is live, all of them will remain  


target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- 
target triple = "x86_64-pc-linux-gnu"

define i32  <at> main() {
   %1 = getelementptr [2 x i8]*  <at> arr1, i64 0, i32 0
   %2 = load i8* %1
   %3 = zext i8 %2 to i32
   ret i32 %3

 <at> arr1 = appending global [2 x i8] [
    i8 1,
    i8 2
], section "mytest"

 <at> arr2 = appending global [2 x i8] [
    i8 3,
    i8 4
], section "mytest"

Since  <at> arr2 is not referenced, I would like it to not appear in the  
final binary, but "clang -fdata-sections" generates:

         .type   arr1, <at> object            #  <at> arr1
         .section        mytest,"aw", <at> progbits
         .globl  arr1
         .ascii  "\001\002"
         .size   arr1, 2

         .type   arr2, <at> object            #  <at> arr2
         .globl  arr2
         .ascii  "\003\004"
         .size   arr2, 2

Alternatively, in case the "appending" linkage type implies "this data  
is also accessible via a getelementptr based on other data in that  
same section, and therefore must remain live", is there another way to  
achieve this?


Marco Alesiani | 1 Aug 12:13 2014

Clang 3.4 yields lambda rvalue reference error while gcc doesn't

I noticed that the following program compiled with clang 3.4 yields an error:

Conversely gcc doesn't (

If the program gets compiled in clang without the '-stdlib=libc++' option it compiles just fine so I suppose it might be a problem in libc++.

A quick search on LLVM's bugzilla for libc++ and lambda doesn't show any outstanding issue. Is this a bug or am I missing something?


LLVM Developers mailing list
LLVMdev <at>
Tobias Grosser | 1 Aug 08:44 2014

Re: Documentation for adding builders and slaves to zorg?

On 01/08/2014 08:40, Eric Fiselier wrote:
> Not quite, That is the documentation I was following.
> I'm hoping to find more information on step #9.

I don't think there is other documentation. I would just look at the 
last commits that added builders. They should show exactly the changes 


P.S: Re-adding llvmdev <at>  mailing list. This keeps our answers and 
discussions available to everyone.
Keno Fischer | 1 Aug 08:31 2014

Building LLVM as a shared library on MinGw (Makefiles)

The sed invocation in tools/llvm-shlib is stripping leading
underscores from symbols. This was breaking the windows dll build on
MinGw for me but I figure since it was in there it must work for
somebody. I'd like to figure out which configurations need the
underscore stripped and which don't. Is there anybody else building
DLLs under MinGw?