<div dir="ltr">Hi James,<div><br></div><div>For first patch of moving SetTheory location is lack of the change of CMakeLists.txt for TableGen folder, so it would trigger cmake configure failure otherwise.</div><div><br></div>
<div><div>--- a/lib/TableGen/CMakeLists.txt</div><div>+++ b/lib/TableGen/CMakeLists.txt</div><div>@@ -6,4 +6,5 @@ add_llvm_library(LLVMTableGen</div><div> TableGenBackend.cpp</div><div> TGLexer.cpp</div><div> TGParser.cpp</div>
<div>+ SetTheory.cpp</div><div> )</div></div><div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-05 8:20 GMT+08:00 Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Woah. This sounds fantastic. I'm at WWDC this week so won't be able to give this an in depth review for a bit. Please don't mistake my silence as lack of interest! If I haven't responded in more depth by early next week, please ping me.<br>
<br>
Jim.<br>
<div><div class="h5"><br>
> On Jun 4, 2014, at 3:39 AM, James Molloy <<a href="mailto:james.molloy@arm.com">james.molloy@arm.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> [Obvious stakeholders put on CC, feel free to add more]<br>
><br>
> NeonEmitter.cpp, the <a href="http://arm_neon.td" target="_blank">arm_neon.td</a> tablegen backend, really needs improving. I<br>
> wanted<br>
> to change the behaviour slightly for big endian, but quickly realised that<br>
> this may<br>
> well be the hack that broke the camel's back. I tried to incrementally<br>
> refactor it<br>
> but to be honest it's beyond repair. The attached patch reimplements it from<br>
> scratch.<br>
> Luckily the testing coverage on this stuff is absolutely massive, both with<br>
> regression tests and the "emperor" random test case generator.<br>
><br>
> The main change is that previously, in <a href="http://arm_neon.td" target="_blank">arm_neon.td</a> a bunch of "Operation"s<br>
> were<br>
> defined with special names. NeonEmitter.cpp knew about these Operations and<br>
> would emit code based on a huge switch. Actually this doesn't make much<br>
> sense -<br>
> the type information was held as strings, so type checking was impossible.<br>
> Also<br>
> TableGen's DAG type actually suits this sort of code generation very well<br>
> (surprising that...)<br>
><br>
> So now every operation is defined in terms of TableGen DAGs. There are a<br>
> bunch<br>
> of operators to use, including "op" (a generic unary or binary operator),<br>
> "call"<br>
> (to call other intrinsics) and "shuffle" (take a guess...). One of the main<br>
> advantages of this apart from making it more obvious what is going on, is<br>
> that<br>
> we have proper type inference. This has two obvious advantages:<br>
><br>
> 1) TableGen can error on bad intrinsic definitions easier, instead of just<br>
> generating wrong code.<br>
> 2) Calls to other intrinsics are typechecked too. So<br>
> we no longer need to work out whether the thing we call needs to be the<br>
> Q-lane<br>
> version or the D-lane version - TableGen knows that itself!<br>
><br>
> Here's an example: before:<br>
><br>
> case OpAbdl: {<br>
> std::string abd = MangleName("vabd", typestr, ClassS) + "(__a, __b)";<br>
> if (typestr[0] != 'U') {<br>
> // vabd results are always unsigned and must be zero-extended.<br>
> std::string utype = "U" + typestr.str();<br>
> s += "(" + TypeString(proto[0], typestr) + ")";<br>
> abd = "(" + TypeString('d', utype) + ")" + abd;<br>
> s += Extend(utype, abd) + ";";<br>
> } else {<br>
> s += Extend(typestr, abd) + ";";<br>
> }<br>
> break;<br>
> }<br>
><br>
> after:<br>
><br>
> def OP_ABDL : Op<(cast "R", (call "vmovl", (cast $p0, "U",<br>
> (call "vabd", $p0,<br>
> $p1))))>;<br>
><br>
> As an example of what happens if you do something wrong now, here's what<br>
> happens<br>
> if you make $p0 unsigned before the call to "vabd" - that is, $p0 -> (cast<br>
> "U", $p0):<br>
><br>
> arm_neon.td:574:1: error: No compatible intrinsic found - looking up<br>
> intrinsic 'vabd(uint8x8_t, int8x8_t)'<br>
> Available overloads:<br>
> - float64x2_t vabdq_v(float64x2_t, float64x2_t)<br>
> - float64x1_t vabd_v(float64x1_t, float64x1_t)<br>
> - float64_t vabdd_f64(float64_t, float64_t)<br>
> - float32_t vabds_f32(float32_t, float32_t)<br>
> ... snip ...<br>
><br>
> This makes it seriously easy to work out what you've done wrong in fairly<br>
> nasty<br>
> intrinsics.<br>
><br>
> As part of this I've massively beefed up the documentation in <a href="http://arm_neon.td" target="_blank">arm_neon.td</a><br>
> too.<br>
><br>
> Things still to do / on the radar:<br>
> - Testcase generation. This was implemented in the previous version and<br>
> not in<br>
> the new one, because<br>
> - Autogenerated tests are not being run. The testcase in test/ differs<br>
> from<br>
> the autogenerated version.<br>
> - There were a whole slew of special cases in the testcase generation<br>
> that just<br>
> felt (and looked) like hacks.<br>
> If someone really feels strongly about this, I can try and reimplement<br>
> it too.<br>
> - Big endian. That's coming soon and should be a very small diff on top of<br>
> this one.<br>
><br>
> Cheers,<br>
><br>
> James<br>
><br>
> ---<br>
> include/clang/Basic/<a href="http://arm_neon.td" target="_blank">arm_neon.td</a> | 653 +++--<br>
> test/CodeGen/arm64_vcvtfp.c | 2 +-<br>
> test/Sema/arm-neon-types.c | 2 +-<br>
> test/Sema/arm64-neon-args.c | 2 +-<br>
> utils/TableGen/NeonEmitter.cpp | 4833<br>
> ++++++++++++++-----------------------<br>
> utils/TableGen/TableGenBackends.h | 3 +<br>
> 6 files changed, 2303 insertions(+), 3192 deletions(-)<br>
</div></div>> <0001-Move-SetTheory-from-utils-TableGen-into-lib-TableGen.patch><br>
> <0001-Rewrite-ARM-NEON-intrinsic-emission-completely.patch><br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</blockquote></div><br></div>