[PATCH ] adding AVX 256bit register support to ghc_x86-64 calling convention (hopefully for both 3.4 and 3.3 point release)

Carter Schonwald carter.schonwald at gmail.com
Mon Jul 8 13:56:35 PDT 2013


Ok, will do,
I should remark that the current tests for vanil x86_32 and x86_64 ghc
calling conventions are using check-next currently, so i was copying that
convention. Should I update the patch to change those to check too?


On Mon, Jul 8, 2013 at 4:54 PM, Stephen Lin <swlin at post.harvard.edu> wrote:

> Hi Carter,
>
> I'm not sure if you can really depend on loads being ordered in the
> order you specify them in the IR; even if they are now, they might not
> be in the future and it will add to the difficulty of testing changes
> later, so it's better not to specify things you don't actually depend
> upon.
>
> Can you change the loads to volatile loads (just put the keyword
> "volatile" after the load) and change the CHECK-NEXT lines to simply
> CHECK? I haven't tried it yet but think that would work and be more
> robust to future changes.
>
> Thanks,
> Stephen
>
> On Mon, Jul 8, 2013 at 1:37 PM, Carter Tazio Schonwald
> <carter.schonwald at gmail.com> wrote:
> > Hey All,
> >
> > currently the GHC calling convention doesnt have support for using the
> AVX
> > 256bit width registers. Attached is a patch that augments the GHC x86-64
> > calling convention with that support when vector types of that size are
> > used.
> >
> > This change has been Ok'd by the GHC HQ devs responsible for the SIMD
> > support recently added to ghc (as well as the principal author of the
> llvm
> > backend for ghc ).  see the ghc ticket here
> > http://hackage.haskell.org/trac/ghc/ticket/8033 for their indications of
> > approval
> >
> > it'd be really great to have this patch in both the 3.4 and the pending
> 3.3
> > point release, because then the next GHC release could get some
> additional
> > work to support AVX2   now rather than later. (in addition to the current
> > support for 128bit simd)
> >
> > i've included the patch and an additional test case in the diff attached
> > below
> >
> > thanks!
> > -Carter
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130708/73a41592/attachment.html>


More information about the llvm-commits mailing list