[haskell-llvm] llvm-general FFI dependencies

Scott West scott.west at inf.ethz.ch
Tue Aug 20 05:36:56 BST 2013


Hello Carter,

The FFI uses the Transform definitions to generate the foreign bindings 
to the individual passes. However, the Transforms are not part of the 
external API (right now) in any way.

But you're right that it makes more sense in the context of the full 
range of LLVM capabilities, not just the AST which -pure is mostly about 
now.

So it's a bit fiddly where to put it; the only reason I advocate -pure 
is that if we're wrong about it going in -ffi then those other packages 
that really need it won't be stuck with the full -ffi bindings just to 
get to the Transforms.

Regards,
Scott

On 19/08/13 23:34, Carter Schonwald wrote:
> doesn't the transforms stuff only make sense in the context of the ffi?
> I'm admitedly a bit confused on this front.
>
>
> On Mon, Aug 19, 2013 at 7:27 PM, Scott West <scott.west at inf.ethz.ch
> <mailto:scott.west at inf.ethz.ch>> wrote:
>
>     Hello Ben,
>
>     Sorry I didn't receive this message from you for some reason,
>     luckily Carter replied to it to reply to me!
>
>     I agree that it's basically out of place in either package: the
>     -pure appears to be just AST, and in -ffi it would only be used for
>     adding passes, so that's a bit weird as well.
>
>     Dependency-wise I think putting it into -pure is better, as every
>     package is likely to use -pure anyway (at least in a hypothetical
>     package hierarchy ;)). Introducing it into -ffi for example would
>     mean that clients who want the Transforms have to drag the -ffi
>     along with it, which may be too much for their needs. So I would
>     nudge it towards -pure.
>
>     On the up-side I think the disadvantages are most aesthetic.
>
>     Regards,
>     Scott
>
>
>         On Mon, Aug 19, 2013 at 4:16 PM, Dr. Benjamin S. Scarlet
>         <roll10 at greynode.net <mailto:roll10 at greynode.net>
>         <mailto:roll10 at greynode.net <mailto:roll10 at greynode.net>>> wrote:
>
>              Scott,
>
>              You asked on IRC about putting the Transforms into the -ffi
>         package. I
>              replied that yes, that option would be weird.
>
>              This option of putting them into the -pure package is also
>         weird.
>
>              I'm torn between the two. Neither one is unacceptable;
>         neither is
>              particularly nice.
>
>              I'm pondering the two, and would welcome arguments in
>         either direction.
>
>              -Ben Scarlet
>
>              On Mon, 2013-08-19 at 09:33 +0200, Scott West wrote:
>               > Hello all,
>               >
>               > I've been looking a bit in the past week at the
>         llvm-general bindings
>               > trying to figure out how to tweeze the FFI part away
>         from the rest.
>               >
>               > As Ben Scarlet indicated, the dependency of the FFI part is
>              largely on
>               > llvm-general-pure. However, there are two other small
>         dependencies on
>               > the llvm-general:
>               >
>               > - LLVM.General.Internal.__InstructionDefs and
>               > - LLVM.General.Transforms
>               >
>               > It seems that the dependency on Internal.InstructionDefs is
>              mostly just
>               > code-sharing, and there is probably a not too difficult
>         solution
>              there.
>               >
>               > For Transforms however, I'm less sure what to do.
>               >
>               > I think a better option is to move it into
>         llvm-general-pure, as it
>               > certainly pure, although it's not really part of the AST
>         (which
>               > llvm-general-pure mostly contains). This would make it that
>               > llvm-general-pure is a dependency for all llvm packages
>         in the
>              future,
>               > allowing us to share a single FFI implementation (the
>         currently
>              hidden
>               > llvm-general one).
>               >
>               > Thoughts?
>               >
>               > Thanks!
>               >
>               > Regards,
>               > Scott
>               >
>               > _________________________________________________
>               > Haskell-llvm mailing list
>               > Haskell-llvm at projects.haskell.__org
>         <mailto:Haskell-llvm at projects.haskell.org>
>              <mailto:Haskell-llvm at projects.__haskell.org
>         <mailto:Haskell-llvm at projects.haskell.org>>
>
>               >
>         http://projects.haskell.org/__cgi-bin/mailman/listinfo/__haskell-llvm
>         <http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm>
>
>
>
>              _________________________________________________
>              Haskell-llvm mailing list
>         Haskell-llvm at projects.haskell.__org
>         <mailto:Haskell-llvm at projects.haskell.org>
>              <mailto:Haskell-llvm at projects.__haskell.org
>         <mailto:Haskell-llvm at projects.haskell.org>>
>         http://projects.haskell.org/__cgi-bin/mailman/listinfo/__haskell-llvm
>         <http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm>
>
>
>
>




More information about the Haskell-llvm mailing list