[llvm-dev] RFC: FileCheck Enhancements
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 14 15:23:39 PDT 2016
> On Sep 14, 2016, at 3:10 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> On Sep 13, 2016, at 8:14 PM, Vedant Kumar <vsk at apple.com> wrote:
>>
>> Let me start by saying that adding a few hard-coded patterns to FileCheck could
>> work well for many of llvm's tests. I'd be perfectly fine with that approach.
>>
>> My thinking was that if it isn't easy to teach FileCheck about new patterns,
>> it's less likely that people will do it. I'm not interested in making FileCheck
>> a general-purpose testing tool, but I would like to use custom patterns to
>> simplify in-tree tests that aren't in *.ll or *.s files.
>>
>> I don't think that all extensions to the FileCheck syntax would cause serious
>> maintainability issues. Being able to define patterns in some tests could
>> actually make them more readable. However, if there isn't a way to extend
>> FileCheck without creating serious readability issues, I agree that we
>> shouldn't do it.
>
> Ok, it sounds like you agree that modes would be a good way to solve the most common case. How about we start with that. After that lands and gets adopted, we can see how big the middle zone served by custom pattern is, and what we are leaving on the table by not supporting it.
How you would define the “modes” without a DSL? Hardcoding them inside FileCheck itself?
It seems that it would make the bar higher to add new pattern, and lock-us with this particular hard-coded solution (i.e. moving to a DSL solution after the fact would be harder).
On the opposite, I would expect that having the “DSL” support would make it easier to create/define these “modes”, even if we don’t use the “advanced DSL" in the tests themselves (we may even be able to forbid the use of these patterns outside of “mode file” if it is a strong concern).
I tend to think that with a low entry bar to create a “mode file”, it may be easier to have for example a “mode file” that defines patterns for some target-specific register format, and include it only in the tests for this particular target.
—
Mehdi
More information about the llvm-dev
mailing list