Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installation failed on debian/jessie #1

Open
josemic opened this issue Nov 17, 2013 · 2 comments
Open

Installation failed on debian/jessie #1

josemic opened this issue Nov 17, 2013 · 2 comments

Comments

@josemic
Copy link

josemic commented Nov 17, 2013

Installed after install instructions:

git clone git://github.com/yiannist/llvm.git llvm
cd llvm/
./configure --enable-optimized --disable-assertions
make -j N (where *N* is the number of CPU cores you want to use for the compilation process)

Installing (changed sudo to su):

su
make install

Result:

llc -load=ErlangGC.so hello_1.ll
Error opening 'ErlangGC.so': ErlangGC.so: cannot open shared object file: No such file or directory
  -load request ignored.
unsupported GC: erlang_gc
0  llc             0x0000000000e6f3b5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37
1  llc             0x0000000000e6f813
2  libpthread.so.0 0x00007fdccf174210
3  llc             0x0000000000b03074 llvm::GCModuleInfo::getFunctionInfo(llvm::Function const&) + 20
4  llc             0x0000000003063528 llvm::GCModuleInfo::getFunctionInfo(llvm::Function const&) + 39191752
Stack dump:
0.  Program arguments: llc -load=ErlangGC.so hello_1.ll 
Segmentation fault

Here should ErlangGC.so be located?

@yiannist
Copy link
Owner

Sorry for that!

The truth is that this documentation is out-dated. In fact, you don't need custom LLVM (i.e., this repository) anymore. The necessary patches for ErLLVM have already been committed upstream and any vanilla LLVM version > 3.2 will work without any extra modifications. Thus, you just have to get a proper (vanilla) version of LLVM.

The GC plugin is now called "erlang" (not "erlang_gc").

Ι have to apologize for the misleading documentation, though.

@josemic
Copy link
Author

josemic commented Nov 20, 2013

These are good news! I'll try again the next days. Thanks.

yiannist pushed a commit that referenced this issue Mar 27, 2014
…ify-libcall

optimize a call to a llvm intrinsic to something that invovles a call to a C
library call, make sure it sets the right calling convention on the call.

e.g.
extern double pow(double, double);
double t(double x) {
  return pow(10, x);
}

Compiles to something like this for AAPCS-VFP:
define arm_aapcs_vfpcc double @t(double %x) #0 {
entry:
  %0 = call double @llvm.pow.f64(double 1.000000e+01, double %x)
  ret double %0
}

declare double @llvm.pow.f64(double, double) #1

Simplify libcall (part of instcombine) will turn the above into:
define arm_aapcs_vfpcc double @t(double %x) #0 {
entry:
  %__exp10 = call double @__exp10(double %x) #1
  ret double %__exp10
}

declare double @__exp10(double)

The pre-instcombine code works because calls to LLVM builtins are special.
Instruction selection will chose the right calling convention for the call.
However, the code after instcombine is wrong. The call to __exp10 will use
the C calling convention.

I can think of 3 options to fix this.

1. Make "C" calling convention just work since the target should know what CC
   is being used.

   This doesn't work because each function can use different CC with the "pcs"
   attribute.

2. Have Clang add the right CC keyword on the calls to LLVM builtin.

   This will work but it doesn't match the LLVM IR specification which states
   these are "Standard C Library Intrinsics".

3. Fix simplify libcall so the resulting calls to the C routines will have the
   proper CC keyword. e.g.
   %__exp10 = call arm_aapcs_vfpcc double @__exp10(double %x) #1

   This works and is the solution I implemented here.

Both solutions #2 and #3 would work. After carefully considering the pros and
cons, I decided to implement #3 for the following reasons.

1. It doesn't change the "spec" of the intrinsics.
2. It's a self-contained fix.

There are a couple of potential downsides.
1. There could be other places in the optimizer that is broken in the same way
   that's not addressed by this.
2. There could be other calling conventions that need to be propagated by
   simplify-libcall that's not handled.

But for now, this is the fix that I'm most comfortable with.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203488 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants