[PATCH] [llvm] [Hexagon] Adding tests, TableGen entries, and code for emitting add opcode.
rafael.espindola at gmail.com
Fri Oct 10 10:10:37 PDT 2014
> With uploading .o files and disassembling them as a test we thought it would be difficult to document a process on how the public can regenerate the .o files if needed or add more in the future if we encounter a bug. We had thought adding unit tests would be more in line with the goals of being a library rather than a file-mover as with our implementation in a different toolchain.
> One thing we could do to address the concern about a huge cpp file would be to break the files up in to logical units based on the instruction category in the documentation. We would have to make some changes internally but if that helps with organization we could make that change. Would you want us to do that when submitting follow up patches with tests?
Even if regenerating the .o files is not trivial before llvm-mc
getting support of the Hexagon assembly, it is probably still way more
maintainable to have
CHECK: some instruction in pseudo hexagon assembly syntax
60 llvm::raw_string_ostream stream(str);
61 llvm::HexagonMCInst inst(llvm::Hexagon::A2_add);
65 Emitter.Emitter->EncodeInstruction(inst, stream, EmptyFixups,
68 ASSERT_EQ(4, str.size());
69 EXPECT_EQ(0x11, static_cast<uint8_t>(str));
70 EXPECT_EQ(0xdf, static_cast<uint8_t>(str));
71 EXPECT_EQ(0x15, static_cast<uint8_t>(str));
72 EXPECT_EQ(0xf3, static_cast<uint8_t>(str))
Using gtests is reasonable for things that are not otherwise exposed
in a tool. No tool in LLVM directly exposes a map, so a gtest is
perfect for testing DenseMap. In the case of encoding, it is exposed
via the assembler/disassembler.
Think of it as a special case of code refactoring. Instead of writing
a c++ test for every instruction, you can use a single program
(llvm-mc) and multiple inputs (instructions in a .o/.s).
More information about the llvm-commits