[PATCH] D46223: Introduce a direct LLVM IR execution UnitTests framework, and add the first such test.

[Dean Michael Berris via Phabricator via llvm-commits]

dberris added a comment.

In https://reviews.llvm.org/D46223#1083668, @chandlerc wrote:

> In https://reviews.llvm.org/D46223#1083663, @dberris wrote:
>
> > I wonder whether it's better/useful to implement these eventually as Google Test / Google Mock matchers. Something to think about in the future maybe.
>
>
> I'm curious how you're imagining doing this? If there is a cleaner way of wiring this up I'm quite interested, as I think we may start to grow more of this style of test once the basic approach is fleshed out...


I don't think this is going to be that different from what you're already doing.

Essentially, you're defining extern (I presume `extern "C" { ...  }`) function stubs which are then code-gen'ed later by some tool (llvm-as or something).

You can make the `check(expected, output)` be one of the Google Mock matchers, which can be used in the `EXPECT_THAT(...)` or `ASSERT_THAT` statements in Google Test. Reference: https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#writing-new-parameterized-matchers-quickly

If these were Google Test unit tests, you'd get the benefit of being able to define the output format, and getting the benefit of the global fixtures along with re-use.

> I don't want to rely on the JIT here, but I actually want to *execute* a program generated by LLVM...

Indeed -- the only difference would be that you can use the existing Google Test macros/matchers for some things, and making the raw byte/data matching more extensible/re-usable.

I can see matchers for the different LLVM-specific data types to be deserving of their own matchers and formatting in case of failure.


Repository:
  rT test-suite

https://reviews.llvm.org/D46223