similar to: [RFC] Formalizing FileCheck Features

On 05/24/2018 08:46 AM, via llvm-dev wrote: > Background > ---------- > > FileCheck [0] is a cornerstone testing tool for the LLVM project. It > has grown new features over the years to meet new needs, but these > sometimes have surprising and counter-intuitive behavior [1]. This > has become even more evident in Joel Denny's recent quest to repair > what seemed like

Hi Paul, On Thu, May 24, 2018 at 9:46 AM, <paul.robinson at sony.com> wrote: > Background > ---------- > > FileCheck [0] is a cornerstone testing tool for the LLVM project. It > has grown new features over the years to meet new needs, but these > sometimes have surprising and counter-intuitive behavior [1]. This > has become even more evident in Joel Denny's

A few replies, then I'll post a revised spec v2 which ought to incorporate all the other feedback. If I missed something, give a shout. Actually, I wish there were a way to do that [constrain DAG to a single line] for the sake of matching unordered text on a single line. SAME after DAGs is as close as I can get to that. Maybe we need a CHECK-DAG-SAME. Hmmm. You know, there were cases

Thanks Joel and Chris, comments inline. >> CHECK: Scans the search range for a pattern match. Fails if no match >> is found.  The end of the match range becomes the start of the search >> range for subsequent directives. >> >> CHECK-SAME: Like CHECK, plus there must be zero newlines prior to the >> start of the match range. > > ... within the search

Hi Joel, That sounds like a very nice idea and definitely a direction I could get behind. However I feel that outside the use case I suggested, this functionality would only be used to compress CHECK lines that contain repeated text, not saying its a bad or good thing though. WDYT? ~Nathan On Fri, 2020-07-17 at 14:52 -0400, Joel E. Denny via cfe-dev wrote: > Hi Nathan, > > On Fri, Jul

Hi Jessica, This time I'm replying all.... On Fri, May 4, 2018 at 12:45 PM, Jessica Paquette <jpaquette at apple.com> wrote: > I would personally like a feature like that in FileCheck because it would > make it a lot easier to write MachineOutliner tests, and would make the > tests significantly smaller and easier to understand. > How do MachineOutliner tests accomplish

Hi, Using FileCheck, I have not found a way to make a group of CHECK-DAG directives match multiple occurrences of a string. For example, I naively thought the following would match successfully: ``` $ cat checks.txt // CHECK: start // CHECK-DAG: foo // CHECK-DAG: foo // CHECK-DAG: bar // CHECK-NEXT: end $ cat input.txt start foo bar foo end $ FileCheck --input-file=input.txt checks.txt

On Wed, May 16, 2018 at 12:24 PM, <paul.robinson at sony.com> wrote: > > > > -----Original Message----- > > From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of Justin > > Bogner > > Sent: Wednesday, May 16, 2018 12:16 PM > > To: llvm-dev > > Cc: jdenny.ornl at gmail.com; Robinson, Paul > > Subject: Re: [llvm-dev] RFC:

On Wed, May 16, 2018 at 12:38 PM, Joel E. Denny <jdenny.ornl at gmail.com> wrote: > On Wed, May 16, 2018 at 12:24 PM, <paul.robinson at sony.com> wrote: > >> >> >> > -----Original Message----- >> > From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of >> Justin >> > Bogner >> > Sent: Wednesday, May 16, 2018

Right now, the tests try to accomplish the following 1. Define a sequence of instructions (e.g a,b,c) 2. Insert that sequence into k places with an unique instruction between them to make sure the outliner will yank them out *without overlaps* 3. Check for k calls to an outlined function 4. Check that the outlined sequence still exists in the program This can result in some pretty long tests

I would personally like a feature like that in FileCheck because it would make it a lot easier to write MachineOutliner tests, and would make the tests significantly smaller and easier to understand. - Jessica > On May 4, 2018, at 8:40 AM, Joel E. Denny via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Using FileCheck, I have not found a way to make a group of

On Mon, May 7, 2018 at 12:56 PM, <paul.robinson at sony.com> wrote: > > 1. In a CHECK-DAG group, don't let the matches for patterns overlap. > > 2. Add a new CHECK-DAG-N directive, where N is some integer, to express > > that a pattern must have N non-overlapping matches. > > I think #1 is much more intuitive and easy to describe/document than #2. > Changing

I just stumbled across r332416, which was modifying a test with multiple identical CHECK-DAG directives, which reminded me I needed to get back to you about this... sorry for the slow response. > From: Joel E. Denny [mailto:jdenny.ornl at gmail.com] >> On Mon, May 7, 2018 at 12:56 PM, <paul.robinson at sony.com> wrote: >>> 1. In a CHECK-DAG group, don't let the matches

Any kind of variable definition on a CHECK-NOT line would seem like it would be asking for trouble. Do we allow text variable definitions on a NOT? False fails are better than false matches. Given that it will fail on a line where you'd expect a match, or possibly for the line to be skipped, it's a matter of refining the match expression, which is something that you have to do sometimes

> 1. In a CHECK-DAG group, don't let the matches for patterns overlap. > 2. Add a new CHECK-DAG-N directive, where N is some integer, to express > that a pattern must have N non-overlapping matches. I think #1 is much more intuitive and easy to describe/document than #2. Changing the meaning of DAG in that way is highly unlikely to affect any existing test, IMO. And if it does, my

Paul Robinson <paul.robinson at sony.com> writes: >> From: Joel E. Denny [mailto:jdenny.ornl at gmail.com] >>> On Mon, May 7, 2018 at 12:56 PM, <paul.robinson at sony.com> wrote: >>>> 1. In a CHECK-DAG group, don't let the matches for patterns overlap. >>>> 2. Add a new CHECK-DAG-N directive, where N is some integer, to express

Hi, TL;DR: Is it ok to allow numeric variables used on same line as defined except for CHECK-NOT and with false negatives? FileCheck does not currently allow a numeric variable from being used on the same line they were defined. I have a tentative patch to add that support but it comes with caveats so before going through review I'd like to get consensus on whether those caveats are

Before addressing the CHECK-NOT case, I’m still unclear about the DAG case. What should the first DAG line match? The regex matching would first attempt to match “10 12” but the expression evaluation would fail; so the DAG candidate wouldn’t match; does this mean the DAG matching does not continue searching, and the test fails? Or would we restart the search…. where? With “0 12” (skipping only

> -----Original Message----- > From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of Justin > Bogner > Sent: Wednesday, May 16, 2018 12:16 PM > To: llvm-dev > Cc: jdenny.ornl at gmail.com; Robinson, Paul > Subject: Re: [llvm-dev] RFC: [FileCheck] CHECK-DAG for multiple > occurrences of string > > Paul Robinson <paul.robinson at sony.com> writes:

Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> writes: > Am Mo., 6. Juli 2020 um 08:55 Uhr schrieb David Greene <david.greene at hpe.com>: >> Is the behavior of CHECK-SAME documented anywhere? It's not on the main >> FileCheck web page. I assumed it started over from the beginning of the >> line but now I'm not sure. > >