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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Gabor Greif-2
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


Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
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.





On Mon, Sep 16, 2013 at 5:14 PM, Gabor Greif <ggreif at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130916/973dd4fb/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

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

Gabor Greif-2
On 9/16/13, Carter Schonwald <carter.schonwald at 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 <ggreif at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>


Reply | Threaded
Open this post in threaded view
|

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

Johan Tibell-2
In reply to this post by Carter Schonwald
We should make sure that someone that understands this issue talks to them
ASAP.


On Mon, Sep 16, 2013 at 2:51 PM, Carter Schonwald <
carter.schonwald at 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.
>
>
>
>
>
> On Mon, Sep 16, 2013 at 5:14 PM, Gabor Greif <ggreif at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130916/fcccfd3c/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

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

Nathan Howell-2
In reply to this post by Gabor Greif-2
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 <ggreif at gmail.com> wrote:

> On 9/16/13, Carter Schonwald <carter.schonwald at 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 <ggreif at 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 at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130916/1de44f88/attachment.htm>