LLVM as a back end for HHVM

Hi All,

Our team at Hip-Hop Virtual Machine (http://hhvm.com) have been experimenting with using LLVM as a code generator for x86-64. We have been successfully running it for quite some time as a secondary back end. We had to modify our version of LLVM and our mods were based on 3.5 release. At this point we feel our requirements have become stable enough to start upstreaming our diffs.

A high-level overview of LLVM changes could be found at:

The set of patches will be loosely based on the above,  as some of our interfaces have changed since we’ve merged with the trunk.

All feedback is welcome. Please let me know if you are interested and I’ll CC you explicitly on the reviews.

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

LiveInterval and Loop Info

Hello to all LLVM Developers.

Given a object from a LiveInterval class, is there any way to know if this Live Interval is part or is inside a loop?


Natanael Ramos
Membro do corpo discente de Ciência da Computação pelo Instituto Federal de
Minas Gerais - Campus Formiga

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

LLVM and strict SSA

Hello to all LLVM Developers.

The LLVM IR is in strict SSA form (i.e. every variable is defined before it is used along every path from the entry to exit point)?
According to the documentation, currently the LLVM IR is in the SSA form, but I don't see additional information about strict SSA form.

The strict SSA form provide opportunities of optimization in register allocation, because is proved that all interference graphs of the IR in strict SSA form are chordal and for those, there are polynomial algorithms for the graph coloring (http://web.cs.ucla.edu/~palsberg/paper/aplas05.pdf).

Natanael Ramos
Membro do corpo discente de Ciência da Computação pelo Instituto Federal de
Minas Gerais - Campus Formiga

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
Nat! via llvm-dev | 3 Sep 17:57 2015

Rerunning TailCallElim at a later stage


from what I have figured out, the pass "TailCallElim" is being done in 
what I would call the "opt" phase of optimization. The "StackColoring" 
is being done in the "llc" phase. opt -> llc, so TailCallElim is always 

Now I would like to add something (my reusealloca idea) in 
"StackColoring" to get rid of some allocas, which inhibit "TailCallElim".

* Is it possible to rerun (if even possible at that stage) the 
"TailCallElim" at this stage ?

* Is it possible to make "StackColoring" into an "opt" pass and try to 
get it ahead of "TailCallElim" ? I guess not, though I can see how 
"RegisterColoring" is dependent on architecture, but I don't really see 
it for allocas.


P.S. AU.addRequired<TailCallElim>(); would not work BTW.
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
Greg Stark via llvm-dev | 3 Sep 13:26 2015

Re: Fuzzing complex programs

On Sun, Aug 30, 2015 at 3:30 PM, Greg Stark <stark <at> mit.edu> wrote:
> To do this effectively I think it would be best to invoke the fuzzer
> from inside Postgres. Essentially provide bindings for Libfuzzer so
> you can I can have Libfuzzer provide all the test cases to repeatedly
> call the internal functions on.
> Is there any example of doing something like this already? Am I taking
> a crazy approach?

So on further inspection it seems the API I want, at least for the
in-process plan is mostly there in LLVMFuzzerNoMain. It would be nice
if I could call the driver with a function pointer and void* and it
would call my callback passing that closure along with the fuzzed
input. But I can probably work around that with a global variable.

I'm actually kind of frustrated by a more basic problem. The build
system. It seems LibFuzzer is meant to be compiled as part of LLVM but
it didn't get compiled when I built LLVM because I didn't build it
with sanitize-coverage enabled. Now I can't get it to build because I
get errors like:

$ for i in *.cpp ; do clang -c -std=c++11 $i ; done
$ clang -std=c++11 *.o
FuzzerDriver.o: In function `fuzzer::ReadTokensFile(char const*)':
FuzzerDriver.cpp:(.text+0x56): undefined reference to
FuzzerDriver.cpp:(.text+0x6d): undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string(char const*, std::allocator<char>
FuzzerDriver.cpp:(.text+0x8d): undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string()'
FuzzerDriver.cpp:(.text+0x96): undefined reference to
FuzzerDriver.cpp:(.text+0xab): undefined reference to
`std::__cxx11::basic_istringstream<char, std::char_traits<char>,
std::char_traits<char>, std::allocator<char> > const&,
FuzzerDriver.cpp:(.text+0x14c): undefined reference to
FuzzerDriver.cpp:(.text+0x166): undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string(char const*, std::allocator<char>
FuzzerDriver.cpp:(.text+0x18f): undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string()'

And I get similar errors if I try to build it using the LLVM CMake
generated makefiles (after running "cmake
-DLLVM_USE_SANITIZE_COVERAGE=1" in the LibFuzzer directory), in fact I
get errors that I need -std=c++11. Do I need to recompile *all* of
llvm as if I was going to fuzz LLVM just to get libfuzzer built?


LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

lld on Windows

What's the current state of affairs regarding lld on Windows - how much of it is supposed to work? The documentation at http://lld.llvm.org/windows_support.html suggests it should pretty much work provided you don't need exceptions or debug info (though that documentation seems to be from last year), but when I tried it on a 'hello world' C program, it gave error messages; is it the case that lld is not yet expected to work on Windows, or that it should and I'm probably getting a command wrong, or something else?
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

Re: RFC: Add "operand bundles" to calls and invokes

On Wed, Sep 2, 2015 at 1:42 PM Sanjoy Das <sanjoy <at> playingwithpointers.com> wrote:
Hi Chandler,

Thanks for replying!

> First, as I think Philip already said, I think it is important that a
> readonly or a readnone attribute on a call is absolute. Optimizations
> shouldn't have to go look for an operand bundle. Instead, we should prevent
> the call-side attributes from being added.

I think Philip's concern was more about the *difference* between the
call side attributes and attributes on the function.

Say you have

define i32 <at> f() {
  ret i32 42

define void <at> g() {
  call void <at> f() [ "foo"(i32 100) ]
  ret void

Now I think we all agree that the call to ` <at> f` cannot be marked as
`readnone` to have deopt semantics.  We can (I suspect without too
much churn) make sure LLVM does not take such a `call` and mark it as

However, `-functionattrs` (and related passes) are still allowed to
mark the *function* (` <at> f`) as `readnone`, and I think it would be very
weird if we disallowed that (since we'll have to iterate through all
of ` <at> f`'s uses).

This brings us to the weird situation where we can have a
not-`readnone` call to a function that's marked `readnone`.  This was
Philip's concern -- the semantics of the call is no longer the most
precise that can be deduced by looking at both the call and function
attributes.  We'd possibly have issues with passes that looked at the
`CS.getCalledFunction()`'s attributes and decided to do an illegal
reordering because the function was marked `readnone`.

While I'm still mulling it over, I think that if we want something like operand bundles, we really need to move to the point where the *only* valid set of attributes to query is the call attributes when trying to understand the semantics of a call instruction. I actually like this model better. It clearly separates the idea that a particular call instruction's semantics are modeled by a particular call instruction attribute set. A particular function's semantics are modeled by *its* attribute set. Depending on the nature of the query, you should look at different ones.

Historically, getting this wrong only manifested in missed optimizations. With the ability to add extra functionality to call instructions (outside of the called function) we inherently introduce the concept of this being a correctness issue. I think we'll have to carefully audit the optimizer here, but I'm not (yet) too worried about the ramifications.

> I think there may be a separate way of specifying all of this that makes
> things clearer. Operand bundles imply that when lowering, the call may be
> wrapped with a call to an external function before and/or after the called
> function, with the bundled operands escaped into those external functions
> which may capture, etc.
> This both gives you the escape semantics, and it gives you something else;
> the runtime function might not return! That should (I think) exactly capture
> the semantic issue you were worried about with deopt. Because control may
> never reach the called function, or may never return to the caller even if
> the callee returns, code motion of side-effects would be clearly prohibited.

This is sort of what I was getting at when I said

"As a meta point, I think the right way to view operand bundles is as
something that *happens* before and after an call / invoke, not as a
set of values being passed around."

But with this scheme, the issue with a function's attributes being out
of sync with its actual semantics at a call site still exists.

I think a reasonable specification is to add a function attribute
`may_deopt_caller`[1].  Only functions that are marked
`may_deopt_caller` can actually access the operand bundles that was
passed to the function at a call site, and `may_deopt_caller` implies
all of the reordering restrictions we are interested in.
`-functionattrs` is not allowed to mark a `may_deopt_caller` function
as `readnone` (say) because they're not.  If we wanted to be really
clever, we could even DCE deopt operand bundles in calls to functions
that are not marked `may_deopt_caller`.

This does bring up the semantic issue of whether `may_deopt_caller` is
truly a property of the callee, or am I just trying to come up with
arbitrary conservative attributes to sweep a complex issue under the
carpet.  I'll have to spend some time thinking about this, but at this
time I think it is the former (otherwise I wouldn't be writhing this
:)) -- typically a callee has to *do* something to deopt its caller,
and that's usually a call to the runtime.  `may_deopt_caller` in this
case is a conservative attribute stating that the callee may execute
such a deopting call.  The most similar existing attribute I can find
is `returns_twice`.

I really think this just happens to be the special case of deopt, and that it is a mistake to design the IR extension based solely on that use case.

Consider many of the other decorator patterns that have been discussed as uses of this IR functionality. If the runtime logic invoked before or after the function can read or write memory other than what the callee does, we are moving to a point where the call instruction's annotations (attributes + operand bundles) introduce a *more restrictive* semantic model than the function attributes alone.

I'm actually much more comfortable with the highly generic approach and eating the cost of teaching the optimizer about this distinction.
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
Ben Swift via llvm-dev | 3 Sep 03:02 2015

LLVM 3.7.0 build errors on Windows

I'm working on a cross-platform project which links (statically) against
LLVM, which I use for MCJIT purposes.

Everything was fine on 3.4.2. I'm just experimenting with upgrading to
3.7.0, and everything works fine on OSX & Linux once I changed my
project to reflect the API updates.

On Windows, I get a bunch of compile errors - hundreds of them, but
variations on a couple of different themes, such as

Error   C3805   '(': unexpected token, expected either '}' or a ','     
  llvm\Support\COFF.h  168
Error   C3646   'Checksum': unknown override specifier                  
llvm\Object\COFF.h              50
Error   C4430   missing type specifier - int assumed. Note: C++ does not
support default-int    llvm\Object\COFF.h      52

All the errors are reported in LLVM header files, mostly
llvm/Support/COFF.h and llvm/Object/COFF.h

I'm using Visual Studio Community 2015, the CXX compiler identification
is MSVC 19.0.23026.0

My CPP includes are:


Now, a couple of things are suspicious: 

- in googling around it seems like there are some problems with
including Windows.h (which I have to include for other reasons) as well
as the LLVM headers, at least with previous versions of LLVM.
- on OSX, I did have to add a -std=c++11 flag before it would compile.
But I thought I didn't need/couldn't do that on Windows?

Does anyone have any idea what might be the problem, or ideas for

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

Testing "normal" cross-compilers versus GPU backends

This note arose from http://reviews.llvm.org/D12506 but the reviewers
felt that we needed a broader audience, because the proposed patch
really didn't solve the entire problem and we had no better ideas.

Mehdi Amini needs to build LLVM with just a GPU backend, and still have
"ninja check" Just Work.  Commits r243958-243960 tried to accomplish
that; however they are too big a hammer, and cause much simpler cross
environments (like mine) to exclude big chunks of very useful tests
(including my favorite, DebugInfo).

FYI, my main cross environment is building on X86 Windows but using
a default target triple for PS4 (which is also X86).

I experimented with building LLVM with just the ARM backend (running on
an X86 workstation) and setting the default triple to some ARM value.
"ninja check" worked fine (without Mehdi's series of commits), so the 
normal kind of cross-compiler environment seems to be happy with how 
things were set up originally.

Mehdi reports building LLVM with the X86 and AMDGPU backends, setting
the default triple to "amdgcn--amdhsa", and getting 200-some failures.

(This does make me wonder about AMDGPU testing in general; how does that
work?  The only places I see lit checks for AMDGPU are in the usual
target-dependent places.)

Mehdi's solution was:
- In lit.cfg, change the existing "native" feature definition from
  "host-triple == target-triple" to also check "and the corresponding
  backend is included."(**)
- Make piles of tests that seemed inapplicable to GPUs depend on the
  "native" feature (through REQUIRES: or in the lit.local.cfg).
- Build LLVM with just the GPU backend, and not set a target triple
  (i.e., it's set to the host triple, typically an X86-something).(*)
  Thus lit.cfg sees matching host and target triples, but the X86
  backend is missing, and so the "native" feature is not set.

[The "native" feature was invented to identify environments where
JIT would work properly. The "host-triple == target-triple" condition
isn't exactly right, but it works well enough.]

The major problem is that these new "native" dependencies are incorrect.
For example the DebugInfo tests don't really require it; they work fine
as long as the default triple has the corresponding backend included,
as my ARM-on-X86 experiment demonstrated.

So, we need some solution that Mehdi can use in a GPU-backend-testing 
workflow, but that does not so drastically interfere with normal 
cross-compiler testing.  Does anybody have any suggestions?


(*) This configuration seems inherently wrong; the default target triple
ought to require having the corresponding backend included, I think.
(**) Which makes this modification superfluous.

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
via llvm-dev | 2 Sep 20:16 2015

IR question re: constants

I'm curious.  Is there a specific technical reason that the high-level
IR doesn't have an instruction to simply set a register to a constant?
This limitation means we cannot hoist an "expensive" constant out of a
loop until we lower the IR to MachineInstrs.  Or more to the point, it
forces backends to undo any such hoisting done by frontends.

Or am I not understanding something?

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
John Criswell via llvm-dev | 2 Sep 20:09 2015

Re: Proposal to add a project to "Projects built with LLVM" - Codasip Studio

On 8/27/15 10:30 AM, Adam Husar via llvm-dev wrote:
> Dear all,
>   I would have a proposal for adding a project to the page 
> http://llvm.org/ProjectsWithLLVM/.
> We successfully use LLVM as a base for a retargetable compiler and 
> below is some information on the project.
> If you would have any comments, questions or if we should improve the 
> text below, please let me know.

I've added an entry on the LLVM projects page.  Please review it to see 
if it is correct.  Also, you use the phrase "design implementation;" I 
suspect that is a typo, but I'm not sure what you meant to say.

We could also add you to the LLVM Users page.  Just let me know if it's 
an open-source or corporate entry for the page.


John Criswell

> ---
> Codasip Studio
> By Codasip Ltd. (link https://www.codasip.com/)
> Codasip Studio is a highly automated development environment that 
> covers all aspects of Application Specific Instruction-set Processor 
> (ASIP) design including LLVM-based C/C++ compiler generation.
> Starting with a high-level description of a processor written in CodAL 
> (Codasip’s processor description language), users are able to generate 
> the design implementation, verification environment, virtual system 
> prototype, and complete redistributable programming environment.
> Codasip Studio includes compiler backend generator that analyses the 
> CodAL description and then automatically generates sources for LLVM 
> backend with support of numerous extensions for ASIP programming. This 
> way, users are able to generate a working C/C++ compiler for their 
> specific architecture within several days.
> ---
> Thank you
>   Adam


John Criswell
Assistant Professor
Department of Computer Science, University of Rochester

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org