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! :) ).
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simdfrags.patch
Type: text/x-patch
Size: 31214 bytes
Desc: Fragment Reorg Patch
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100709/520c2bbf/attachment.bin>
Hi David, On Fri, Jul 9, 2010 at 3:25 PM, David Greene <dag at cray.com> wrote:> 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! :) ). > > 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?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. Thanks, -- Bruno Cardoso Lopes http://www.brunocardoso.cc
Bruno Cardoso Lopes <bruno.cardoso at 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
Bruno Cardoso Lopes <bruno.cardoso at 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