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

[Stephen Lin]

As I understand it, volatile just means that the load will not be
reordered with respect to other volatile loads or stores, so I don't
know why it would break the test. I'll try it locally.

Changing CHECK-NEXT to CHECK just means you are not longer depending
on the lines being immediately after each other, but you are still
depending on the loads being scheduled in the order you specified.

Stephen

On Mon, Jul 8, 2013 at 2:12 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> 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
>> >> >
>> >
>> >
>
>