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

[Carter Schonwald]

hrmm, I think those loads should not be volatile, because the semantics of
ghc means that function args are "immutable".

(tellingly, the test example fails with the volatile annotation and CHECK
instead of CHECK-NEXT, but works just fine with CHECK and no volatile)

attached is the update of the proposed patch, passes the test suite again,
i'll email the list with a separate patch for those test examples shortly


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

> It's not that big of a deal, I think, but it's probably better to
> change them if you can. People often introduce changes that cause
> existing tests to fail just because the tests are over-specified and
> it takes time for the person making the change to figure out if the
> change actually breaks something important or not.
>
> You should probably split the cleanup of the exiting tests and the new
> changes into two separate patch files (one for the changes to the
> existing tests, and one for the new stuff), since they're disjoint.
>
> -Stephen
>
> On Mon, Jul 8, 2013 at 1:56 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> > 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/55cd24fa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghc-x86-64-avx-Check.diff
Type: application/octet-stream
Size: 4299 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130708/55cd24fa/attachment.obj>