[PATCH] Start of SIMD Reorg

Now that Bruno is putting in some AVX stuff, it's a good motivator to
move my x86 SIMD reorg work into trunk (and got management to agree to
prioritize it - Thanks Bruno! :slight_smile: ).

Attached is the first patch of many to accomplish this. The overall
goal is to have all x86 SIMD instructions share a set of common patterns
so that we can have a more maintainable machine description (e.g. SS,
SD, PS, PD, 128-bit, 256-bit ADD all look similar other than opcode
prefixes).

This patch merely moves some common pattern fragments (memop,
alignedload, etc.) to a file separate from X86InstrSSE.td so that all
current x86 SIMD implementations can still use the classes while the
transition happens.

Ok to commit?

                              -Dave

simdfrags.patch (30.5 KB)

Hi David,

Bruno Cardoso Lopes <bruno.cardoso@gmail.com> writes:

Ok to commit?

I'm Ok with this patch.

Despite that, I think we should discuss the ones to come, If you really go
"tablegen auto generates everything" as I've noticed in some tablegen patches
you commited, there's a great chance the sse/avx code would become unreadable,
I think this is harder to maintain and improve.

Of course we will discuss things as we go. Since you've done a good
deal of AVX implementation already, we can think of my patches as
a reorg to consolidate the pattern space.

This will hopefully become clearer as I sned stuff for comment. I also
have some blog posts ready to go.

                                -Dave

When you want to post them, let me know.

-Chris

Bruno Cardoso Lopes <bruno.cardoso@gmail.com> writes:

This patch merely moves some common pattern fragments (memop,
alignedload, etc.) to a file separate from X86InstrSSE.td so that all
current x86 SIMD implementations can still use the classes while the
transition happens.

Ok to commit?

I'm Ok with this patch.

So I'm getting some mysterious failures with this.

Currently TOT is failing six tests, which look like this:

[x86_64-off-dbg]: FAIL: /ptmp/dag/llvm-project.official/llvm/trunk/test/FrontendC/2010-06-28-DbgLocalVar.c
[x86_64-off-dbg]: Failed with exit(1) at line 2
[x86_64-off-dbg]: while running: grep DW_TAG_structure_type 2010-06-28-DbgLocalVar.c.tmp.s | count 2
[x86_64-off-dbg]: Expected 2 lines, got 0.

I am getting some additional failures with my patch that look
like this:

[x86_64-com-dbg]: FAIL: /ptmp/dag/llvm-project.modified.commit/llvm/trunk/test/FrontendC/2010-05-18-asmsched.c
[x86_64-com-dbg]: Failed with exit(1) at line 1
[x86_64-com-dbg]: while running: /cray/css/compiler/cost/tools/llvm-tools/llvm/install.trunk.commit.debug/x86_64-unknown-linux-gnu/bin/llvm-gcc -emit-llvm -w /ptmp/dag/llvm-project.modified.commit/llvm/trunk/test/FrontendC/2010-05-18-asmsched.c -c -O3 -m64 -emit-llvm -o - | llc -march=x86-64 -mtriple=x86_64-apple-darwin | FileCheck /ptmp/dag/llvm-project.modified.commit/llvm/trunk/test/FrontendC/2010-05-18-asmsched.c
[x86_64-com-dbg]: /ptmp/dag/llvm-project.modified.commit/llvm/trunk/test/FrontendC/2010-05-18-asmsched.c:7:11: error: expected string not found in input
[x86_64-com-dbg]: // CHECK: movq %rdi, %r9
[x86_64-com-dbg]: ^
[x86_64-com-dbg]: <stdin>:26:2: note: scanning from here
[x86_64-com-dbg]: ## InlineAsm Start
[x86_64-com-dbg]: ^
[x86_64-com-dbg]: <stdin>:26:13: note: possible intended match here
[x86_64-com-dbg]: ## InlineAsm Start
[x86_64-com-dbg]: ^
[x86_64-com-dbg]:

All of the failures (both TOT and with my patch) are in the FrontendC
and FrontendC++ suites.

My patch literally does nothing but move some TableGen code from one .td
file to another. It does not even change the "relative" order of the
TableGen code as the movement is from the beginning of X86InstrSSE.td to
the end of X86InstrFragmentsSIMD.td which is included immediately before
X86InstrSSE.td. The failing tests aren't even looking for SSE code.

I don't see how this patch could cause any failures.

Is somethinmg tricky going on with the Frontend* tests at the moment?

                         -Dave

I just updated and ran everything and it's working fine for me. (Note that
I haven't tested with your patch.)

-eric

Eric Christopher <echristo@apple.com> writes: