Re: Runtime error using LLVM bitcode execution

2014-03-02 Thread Nathan Howell
Slightly related... is it possible to implement the evil mangler as an LLVM
MC optimization instead of a standalone post-processor? Seems like it could
be faster.


On Sun, Mar 2, 2014 at 11:39 PM, Benzinger, Ralph
ralph.benzin...@sap.comwrote:

 Hallo Simon,

 Oh, I see ...  Well, that's unfortunate, as we're working with the .ll
 files rather than the .s files.

 I guess I'll try to create my own mangler that will work on the .ll files
 instead, if that's feasible ...

 Regards
 Ralph


 -Original Message-
 From: Simon Marlow [mailto:marlo...@gmail.com]
 Sent: Freitag, 28. Februar 2014 10:43
 To: Benzinger, Ralph; ghc-devs@haskell.org
 Subject: Re: Runtime error using LLVM bitcode execution

 You need to run it against the assembly file (.s) that LLVM generates,
 not the .ll file.

 Cheers,
 Simon

 On 28/02/2014 08:48, Benzinger, Ralph wrote:
  Hello Simon,
 
  Thanks for your suggestion!  I ran the LLVM mangler against the hfun.ll
 file, but it didn't make any changes to the code at all.  (My understanding
 is that I can leave the hfun_stub alone.)
 
  Am I missing something?
 
  Regards
  Ralph
 
 
  -Original Message-
  From: Simon Marlow [mailto:marlo...@gmail.com]
  Sent: Mittwoch, 26. Februar 2014 09:11
  To: Benzinger, Ralph; ghc-devs@haskell.org
  Subject: Re: Runtime error using LLVM bitcode execution
 
  My guess is that this isn't working because GHC needs to post-process
  the assembly generated by LLVM to support tables-next-to-code.  You
  could extract this phase from GHC (it's just one module, in
  compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.
 
  Cheers,
  Simon
 
  On 21/02/2014 16:02, Benzinger, Ralph wrote:
  Hello,
 
  My apologies in advance if this mailing list is not the appropriate
  address for posting my problem with the GHC runtime, but it seemed
  like the best option on the GHC home page.
 
  I'm trying to execute standalone Haskell functions exported via FFI
  and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
  following runtime error:
 
  lu003107:~/hs-bitcode ./bce_so hsallinone.bc
  hs_init complete
  hs_add_root complete
  hsallinone: internal error: stg_ap_p_ret
(GHC version 7.6.3 for x86_64_unknown_linux)
Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
  0  bce_so   0x00d6b310
  1  bce_so   0x00d6b53b
  2  bce_so   0x00d6ba1c
  3  libpthread.so.0  0x7f7683298800
  4  libc.so.60x7f7682592b35 gsignal + 53
  5  libc.so.60x7f7682594111 abort + 385
  6  libHSrts-ghc7.6.3.so 0x7f7683f6ca21 rtsFatalInternalErrorFn +
 177
  7  libHSrts-ghc7.6.3.so 0x7f7683f6cce1 barf + 145
  8  libHSrts-ghc7.6.3.so 0x7f7683f8a24a stg_ap_p_info + 130
  Stack dump:
  0.  Program arguments: ./bce_so hsallinone.bc
  Aborted
 
  This is what I do:
 
  I have a function hfun.hs that exports a function
 
foreign export ccall hfun :: CInt - CInt
 
  and a wrapper cmain.c that calls this function:
 
#include HsFFI.h
#include hfun_stub.h
extern void __stginit_HFun(void);
#include stdio.h
 
int main(int argc, char *argv[])
{
   hs_init(argc, argv);
   printf(hs_init complete\n);
 
   hs_add_root(__stginit_HFun);
   printf(hs_add_root complete\n);
 
   int i = hfun(42);
   printf(hfun(42) = %d\n, i);
 
   hs_exit();
   return 0;
}
 
  To generate a callable bitcode file I use these commands:
 
$ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
$ llvm-as hfun.ll
$ cp /tmp/... hfun_stub.c
$ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include
 hfun_stub.c
$ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
$ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
 
  My main program bce_so loads the linked bitcode and feeds it to the
  LLVM execution engine.  All required Haskell runtime libraries are
  linked dynamically against bce_so.
 
  Could you kindly provide some insight on whether this runtime error is
  due to a bug with GHC (unlikely) or rather some negligence in my
  setup?  Or does the issue highlight some principal limitation in my
  (admittedly somewhat naive) approach of using LLVM -- threading
  support, maybe?
 
  Note that compiling hfun.hs/cmain.c into a .so and executing
  everything natively using ldload() works flawlessly.
 
  Regards
  Ralph
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


GeneralizedNewtypeDeriving regression in HEAD?

2013-12-26 Thread Nathan Howell
I can't file a trac ticket at the meny but wanted to see if this is a
bug... This is an excerpt from llvm-general that compiles on 7.6.3 but
doesn't without ImpredicativeTypes enabled on HEAD:
https://gist.github.com/NathanHowell/8138977

thanks,
-n
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: [FYI] LLVM: function prefix data (a.k.a. tables-next-to-code) committed

2013-09-16 Thread Nathan Howell
May not be mandatory but it certainly just emits the values directly before
the prologue... I'm guessing this doesn't affect IR level optimizations but
likely breaks machine code optimizations without a relative jump to the
body in the prefix-data.

https://gist.github.com/NathanHowell/6589820

-n


On Mon, Sep 16, 2013 at 3:09 PM, Gabor Greif ggr...@gmail.com wrote:

 On 9/16/13, Carter Schonwald carter.schonw...@gmail.com wrote:
  yup! its exciting.
 
  we were talking about this a bit earlier today on #haskell-llvm, and it
  sounds doable.
  There were some concerns that folks had, but hopefully we can give the
 llvm
  devs feedback about this before its finalized in LLVM 3.4 so it doesn't
  come with any performance caveats for ghc.

 I almost sobered when I read that there must be a machine instruction
 embedded in the prefix, but looking at the testcases this doesn't
 appear like being mandatory. The prefix can be a simple struct, just
 like TNTC.

 
 
  On Mon, Sep 16, 2013 at 5:14 PM, Gabor Greif ggr...@gmail.com wrote:
 
  This looks pretty exiting for LLVM IR-generation:
 
 
 
 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042.html
 
  GHC 7.10 might generate LLVM IR including embedded tables without
  resorting to linker tricks/postprocessing when targeting LLVM 3.4!
 
  The relevant LLVM bug is http://llvm.org/bugs/show_bug.cgi?id=14080
 
  and GHC Trac: http://ghc.haskell.org/trac/ghc/ticket/4213
 
  Cheers,
 
  Gabor
  ___
  ghc-devs mailing list
  ghc-devs@haskell.org
  http://www.haskell.org/mailman/listinfo/ghc-devs
 
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs