[PATCH] [llvm] [Hexagon] Adding tests, TableGen entries, and code for emitting add opcode.

colinl at codeaurora.org colinl at codeaurora.org
Fri Oct 10 08:58:28 PDT 2014

>>! In D5624#14, @rafael wrote:
>> Disassembler tests might be possible, I hadn't considered that before.  We had thought the gtests would be sufficient since the inputs and outputs shouldn't vary as time goes on since the instructions and their encoding are tied to existing hardware.
>> What types of problems with clang-format tests are we looking to avoid?  We have a fair number of instructions with running gtests we have pretty much prepped for upstreaming and haven't encountered any problems but we want to avoid something maybe we haven't thought of.
> With gtest you end up with a massive .cpp files which are hard to read
> and hard to check against a native tool. IMHO it is also way too easy
> to simply write gtest tests that just check that copy and paste is
> working :-(
> If you checkin a .o and test disassembly, things are much better IMHO:
> * You can check the .o agains a native tool or even the CPU.
> * You get an end to end test.
> * FileCheck error makes it very easy to see what instruction failed to
> disassemble.
> Cheers,
> Rafael

Test quality is a good point.  What we've been doing internally to keep the test quality high is using them as our source-of-truth for correct encoding.  We thought unit-tests would be more of a library-centric approach rather than a toolchain-centric with files or calls out to other tools in the system.

Do you think we can push up a few more of these unit tests in the next week or so and see how it shapes up or is this more of a blocking issue?  I think in the end you'll be happy with the quality.


More information about the llvm-commits mailing list