[llvm-dev] Syntax for FileCheck numeric variables and expressions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Syntax for FileCheck numeric variables and expressions

Bruce Hoult via llvm-dev
Hi all,

I've written a patch to extend FileCheck to support matching
arithmetic expressions involving variable [1] (eg. to match REG+1
where REG is a variable with a numeric value). It was suggested to me
in the review to introduce the concept of numeric variable and to
allow for specifying the base the value are written in.

[1] https://reviews.llvm.org/D49084

I think the syntax should satisfy the below requirements:

* based off the [[]] construct since anything else might overload an
existing valid syntax (eg. $$ is supposed to match literally now)
* consistent with syntax for expressions using @LINE
* consistent with using ':' to define regular variable
* allows to specify base of the number a numeric variable is being set to
* allows to specify base of the result of the numeric expression

I've come up with the following syntax for which I'd like feedback:

Numeric variable definition: [[#X<base:]] (eg. [[#ADDR<16:]]) where X
is the numeric variable being defined and <base is optional in which
case base defaults to 10
Numeric variable use: [[#X>base]] (eg. [[#ADDR]]>2) where <base is
optional in which case base defaults 10
Numeric expression: [[exp>base]] (eg. [[#ADDR+2>16]] where expression
must contain at least one numeric variable


I'm not a big fan of the > for the output base being inside the
expression but [[exp]]>base would match >base literally.

Any suggestions / opinions?

Best regards,

Thomas
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Syntax for FileCheck numeric variables and expressions

Bruce Hoult via llvm-dev
Hi Thomas,

In general, I think this is a good proposal. However, I don't think that using ">" or "<" to specify base (at least alone) is a good idea, as it might clash with future ideas to do comparisons etc. I also think it would be nice to have the syntax consistent between definition and use. My first thought on a reasonable alternative was to use commas to separate the two parts, so something like:

[[# VAR, 16:]] to capture a hexadecimal number (where the spaces are optional). [[# VAR, 16]] to use a variable, converted to a hexadecimal string. In both cases, the base component is optional, and defaults to decimal.

This led me to thing that it might be better to use something similar to printf style for the latter half, so to capture a hexadecimal number with a leading "0x" would be: "0x[[# VAR, %x:]]" and to use it would be "0x[[# VAR, %x]]". Indeed, that would allow straightforward conversions between formats, so say you defined it by capturing a decimal integer and using it to match a hexadecimal in upper case, with leading 0x and 8 digits following the 0x:

CHECK: [[# VAR, %d:]] # Defines
CHECK: 0x[[# VAR + 1, %8X]] # Uses

Of course, if we go down that route, it would probably make more sense to reverse the two sides (e.g. to become "[[# %d, VAR:]]" to capture a decimal and "[[# %8X, VAR + 1]]" to use it).

Regards,

James

On 12 July 2018 at 15:34, Thomas Preudhomme via llvm-dev <[hidden email]> wrote:
Hi all,

I've written a patch to extend FileCheck to support matching
arithmetic expressions involving variable [1] (eg. to match REG+1
where REG is a variable with a numeric value). It was suggested to me
in the review to introduce the concept of numeric variable and to
allow for specifying the base the value are written in.

[1] https://reviews.llvm.org/D49084

I think the syntax should satisfy the below requirements:

* based off the [[]] construct since anything else might overload an
existing valid syntax (eg. $$ is supposed to match literally now)
* consistent with syntax for expressions using @LINE
* consistent with using ':' to define regular variable
* allows to specify base of the number a numeric variable is being set to
* allows to specify base of the result of the numeric expression

I've come up with the following syntax for which I'd like feedback:

Numeric variable definition: [[#X<base:]] (eg. [[#ADDR<16:]]) where X
is the numeric variable being defined and <base is optional in which
case base defaults to 10
Numeric variable use: [[#X>base]] (eg. [[#ADDR]]>2) where <base is
optional in which case base defaults 10
Numeric expression: [[exp>base]] (eg. [[#ADDR+2>16]] where expression
must contain at least one numeric variable


I'm not a big fan of the > for the output base being inside the
expression but [[exp]]>base would match >base literally.

Any suggestions / opinions?

Best regards,

Thomas
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Syntax for FileCheck numeric variables and expressions

Bruce Hoult via llvm-dev
Hi James,

I like that suggestion very much but I think keeping the order of the
two sides as initially proposed makes more sense. In printf/scanf the
string is first because the primary use of these functions is to do
I/O and so you first specify what you are going to output/input and
then where to capture variables. The primary objective of FileCheck
variables and expressions is to capture/print them, the specifier is
an addon to allow some conversion. Does it make sense?

In the interest of speeding things up I plan to start implementing
this proposal starting tomorrow unless someone gives some more
feedback.

Best regards,

Thomas

On Fri, 13 Jul 2018 at 15:51, James Henderson
<[hidden email]> wrote:

>
> Hi Thomas,
>
> In general, I think this is a good proposal. However, I don't think that using ">" or "<" to specify base (at least alone) is a good idea, as it might clash with future ideas to do comparisons etc. I also think it would be nice to have the syntax consistent between definition and use. My first thought on a reasonable alternative was to use commas to separate the two parts, so something like:
>
> [[# VAR, 16:]] to capture a hexadecimal number (where the spaces are optional). [[# VAR, 16]] to use a variable, converted to a hexadecimal string. In both cases, the base component is optional, and defaults to decimal.
>
> This led me to thing that it might be better to use something similar to printf style for the latter half, so to capture a hexadecimal number with a leading "0x" would be: "0x[[# VAR, %x:]]" and to use it would be "0x[[# VAR, %x]]". Indeed, that would allow straightforward conversions between formats, so say you defined it by capturing a decimal integer and using it to match a hexadecimal in upper case, with leading 0x and 8 digits following the 0x:
>
> CHECK: [[# VAR, %d:]] # Defines
> CHECK: 0x[[# VAR + 1, %8X]] # Uses
>
> Of course, if we go down that route, it would probably make more sense to reverse the two sides (e.g. to become "[[# %d, VAR:]]" to capture a decimal and "[[# %8X, VAR + 1]]" to use it).
>
> Regards,
>
> James
>
> On 12 July 2018 at 15:34, Thomas Preudhomme via llvm-dev <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I've written a patch to extend FileCheck to support matching
>> arithmetic expressions involving variable [1] (eg. to match REG+1
>> where REG is a variable with a numeric value). It was suggested to me
>> in the review to introduce the concept of numeric variable and to
>> allow for specifying the base the value are written in.
>>
>> [1] https://reviews.llvm.org/D49084
>>
>> I think the syntax should satisfy the below requirements:
>>
>> * based off the [[]] construct since anything else might overload an
>> existing valid syntax (eg. $$ is supposed to match literally now)
>> * consistent with syntax for expressions using @LINE
>> * consistent with using ':' to define regular variable
>> * allows to specify base of the number a numeric variable is being set to
>> * allows to specify base of the result of the numeric expression
>>
>> I've come up with the following syntax for which I'd like feedback:
>>
>> Numeric variable definition: [[#X<base:]] (eg. [[#ADDR<16:]]) where X
>> is the numeric variable being defined and <base is optional in which
>> case base defaults to 10
>> Numeric variable use: [[#X>base]] (eg. [[#ADDR]]>2) where <base is
>> optional in which case base defaults 10
>> Numeric expression: [[exp>base]] (eg. [[#ADDR+2>16]] where expression
>> must contain at least one numeric variable
>>
>>
>> I'm not a big fan of the > for the output base being inside the
>> expression but [[exp]]>base would match >base literally.
>>
>> Any suggestions / opinions?
>>
>> Best regards,
>>
>> Thomas
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Syntax for FileCheck numeric variables and expressions

Bruce Hoult via llvm-dev


> -----Original Message-----
> From: llvm-dev [mailto:[hidden email]] On Behalf Of
> Thomas Preudhomme via llvm-dev
> Sent: Monday, July 16, 2018 6:24 AM
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [llvm-dev] Syntax for FileCheck numeric variables and
> expressions
>
> Hi James,
>
> I like that suggestion very much but I think keeping the order of the
> two sides as initially proposed makes more sense. In printf/scanf the
> string is first because the primary use of these functions is to do
> I/O and so you first specify what you are going to output/input and
> then where to capture variables. The primary objective of FileCheck
> variables and expressions is to capture/print them, the specifier is
> an addon to allow some conversion. Does it make sense?

My immediate reaction is that I'd rather not have FileCheck get into
the business of handling printf specifiers.  OTOH, while LLVM tools
do typically print lowercase hex, that's not guaranteed, and looking
at the output of other tools can be useful too.  So, a way to specify
the case for a hex conversion seems worthwhile.

I had also been thinking in terms of the trailing colon to distinguish
definition from use, as James suggested, that's sort-of consistent
with the current syntax.

This is starting to make parsing the insides of [[]] much more involved,
so you'll want to pay attention to making that code well-structured and
readable.
--paulr

>
> In the interest of speeding things up I plan to start implementing
> this proposal starting tomorrow unless someone gives some more
> feedback.
>
> Best regards,
>
> Thomas
>
> On Fri, 13 Jul 2018 at 15:51, James Henderson
> <[hidden email]> wrote:
> >
> > Hi Thomas,
> >
> > In general, I think this is a good proposal. However, I don't think that
> using ">" or "<" to specify base (at least alone) is a good idea, as it
> might clash with future ideas to do comparisons etc. I also think it would
> be nice to have the syntax consistent between definition and use. My first
> thought on a reasonable alternative was to use commas to separate the two
> parts, so something like:
> >
> > [[# VAR, 16:]] to capture a hexadecimal number (where the spaces are
> optional). [[# VAR, 16]] to use a variable, converted to a hexadecimal
> string. In both cases, the base component is optional, and defaults to
> decimal.
> >
> > This led me to thing that it might be better to use something similar to
> printf style for the latter half, so to capture a hexadecimal number with
> a leading "0x" would be: "0x[[# VAR, %x:]]" and to use it would be "0x[[#
> VAR, %x]]". Indeed, that would allow straightforward conversions between
> formats, so say you defined it by capturing a decimal integer and using it
> to match a hexadecimal in upper case, with leading 0x and 8 digits
> following the 0x:
> >
> > CHECK: [[# VAR, %d:]] # Defines
> > CHECK: 0x[[# VAR + 1, %8X]] # Uses
> >
> > Of course, if we go down that route, it would probably make more sense
> to reverse the two sides (e.g. to become "[[# %d, VAR:]]" to capture a
> decimal and "[[# %8X, VAR + 1]]" to use it).
> >
> > Regards,
> >
> > James
> >
> > On 12 July 2018 at 15:34, Thomas Preudhomme via llvm-dev <llvm-
> [hidden email]> wrote:
> >>
> >> Hi all,
> >>
> >> I've written a patch to extend FileCheck to support matching
> >> arithmetic expressions involving variable [1] (eg. to match REG+1
> >> where REG is a variable with a numeric value). It was suggested to me
> >> in the review to introduce the concept of numeric variable and to
> >> allow for specifying the base the value are written in.
> >>
> >> [1] https://reviews.llvm.org/D49084
> >>
> >> I think the syntax should satisfy the below requirements:
> >>
> >> * based off the [[]] construct since anything else might overload an
> >> existing valid syntax (eg. $$ is supposed to match literally now)
> >> * consistent with syntax for expressions using @LINE
> >> * consistent with using ':' to define regular variable
> >> * allows to specify base of the number a numeric variable is being set
> to
> >> * allows to specify base of the result of the numeric expression
> >>
> >> I've come up with the following syntax for which I'd like feedback:
> >>
> >> Numeric variable definition: [[#X<base:]] (eg. [[#ADDR<16:]]) where X
> >> is the numeric variable being defined and <base is optional in which
> >> case base defaults to 10
> >> Numeric variable use: [[#X>base]] (eg. [[#ADDR]]>2) where <base is
> >> optional in which case base defaults 10
> >> Numeric expression: [[exp>base]] (eg. [[#ADDR+2>16]] where expression
> >> must contain at least one numeric variable
> >>
> >>
> >> I'm not a big fan of the > for the output base being inside the
> >> expression but [[exp]]>base would match >base literally.
> >>
> >> Any suggestions / opinions?
> >>
> >> Best regards,
> >>
> >> Thomas
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> [hidden email]
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Syntax for FileCheck numeric variables and expressions

Bruce Hoult via llvm-dev
To be clear, I do not intend to add support for hex specifier in the
current patch, I just want to make sure the syntax we choose is going
to allow it later. My immediate use case is decimal integer and I
intend to write the code so that it's easy to extend to more type of
numeric variables and expressions later. This way we'll only add
specifier that are actually required by actual testcases.

Best regards,

Thomas
On Mon, 16 Jul 2018 at 18:39, <[hidden email]> wrote:

>
>
>
> > -----Original Message-----
> > From: llvm-dev [mailto:[hidden email]] On Behalf Of
> > Thomas Preudhomme via llvm-dev
> > Sent: Monday, July 16, 2018 6:24 AM
> > To: [hidden email]
> > Cc: [hidden email]
> > Subject: Re: [llvm-dev] Syntax for FileCheck numeric variables and
> > expressions
> >
> > Hi James,
> >
> > I like that suggestion very much but I think keeping the order of the
> > two sides as initially proposed makes more sense. In printf/scanf the
> > string is first because the primary use of these functions is to do
> > I/O and so you first specify what you are going to output/input and
> > then where to capture variables. The primary objective of FileCheck
> > variables and expressions is to capture/print them, the specifier is
> > an addon to allow some conversion. Does it make sense?
>
> My immediate reaction is that I'd rather not have FileCheck get into
> the business of handling printf specifiers.  OTOH, while LLVM tools
> do typically print lowercase hex, that's not guaranteed, and looking
> at the output of other tools can be useful too.  So, a way to specify
> the case for a hex conversion seems worthwhile.
>
> I had also been thinking in terms of the trailing colon to distinguish
> definition from use, as James suggested, that's sort-of consistent
> with the current syntax.
>
> This is starting to make parsing the insides of [[]] much more involved,
> so you'll want to pay attention to making that code well-structured and
> readable.
> --paulr
>
> >
> > In the interest of speeding things up I plan to start implementing
> > this proposal starting tomorrow unless someone gives some more
> > feedback.
> >
> > Best regards,
> >
> > Thomas
> >
> > On Fri, 13 Jul 2018 at 15:51, James Henderson
> > <[hidden email]> wrote:
> > >
> > > Hi Thomas,
> > >
> > > In general, I think this is a good proposal. However, I don't think that
> > using ">" or "<" to specify base (at least alone) is a good idea, as it
> > might clash with future ideas to do comparisons etc. I also think it would
> > be nice to have the syntax consistent between definition and use. My first
> > thought on a reasonable alternative was to use commas to separate the two
> > parts, so something like:
> > >
> > > [[# VAR, 16:]] to capture a hexadecimal number (where the spaces are
> > optional). [[# VAR, 16]] to use a variable, converted to a hexadecimal
> > string. In both cases, the base component is optional, and defaults to
> > decimal.
> > >
> > > This led me to thing that it might be better to use something similar to
> > printf style for the latter half, so to capture a hexadecimal number with
> > a leading "0x" would be: "0x[[# VAR, %x:]]" and to use it would be "0x[[#
> > VAR, %x]]". Indeed, that would allow straightforward conversions between
> > formats, so say you defined it by capturing a decimal integer and using it
> > to match a hexadecimal in upper case, with leading 0x and 8 digits
> > following the 0x:
> > >
> > > CHECK: [[# VAR, %d:]] # Defines
> > > CHECK: 0x[[# VAR + 1, %8X]] # Uses
> > >
> > > Of course, if we go down that route, it would probably make more sense
> > to reverse the two sides (e.g. to become "[[# %d, VAR:]]" to capture a
> > decimal and "[[# %8X, VAR + 1]]" to use it).
> > >
> > > Regards,
> > >
> > > James
> > >
> > > On 12 July 2018 at 15:34, Thomas Preudhomme via llvm-dev <llvm-
> > [hidden email]> wrote:
> > >>
> > >> Hi all,
> > >>
> > >> I've written a patch to extend FileCheck to support matching
> > >> arithmetic expressions involving variable [1] (eg. to match REG+1
> > >> where REG is a variable with a numeric value). It was suggested to me
> > >> in the review to introduce the concept of numeric variable and to
> > >> allow for specifying the base the value are written in.
> > >>
> > >> [1] https://reviews.llvm.org/D49084
> > >>
> > >> I think the syntax should satisfy the below requirements:
> > >>
> > >> * based off the [[]] construct since anything else might overload an
> > >> existing valid syntax (eg. $$ is supposed to match literally now)
> > >> * consistent with syntax for expressions using @LINE
> > >> * consistent with using ':' to define regular variable
> > >> * allows to specify base of the number a numeric variable is being set
> > to
> > >> * allows to specify base of the result of the numeric expression
> > >>
> > >> I've come up with the following syntax for which I'd like feedback:
> > >>
> > >> Numeric variable definition: [[#X<base:]] (eg. [[#ADDR<16:]]) where X
> > >> is the numeric variable being defined and <base is optional in which
> > >> case base defaults to 10
> > >> Numeric variable use: [[#X>base]] (eg. [[#ADDR]]>2) where <base is
> > >> optional in which case base defaults 10
> > >> Numeric expression: [[exp>base]] (eg. [[#ADDR+2>16]] where expression
> > >> must contain at least one numeric variable
> > >>
> > >>
> > >> I'm not a big fan of the > for the output base being inside the
> > >> expression but [[exp]]>base would match >base literally.
> > >>
> > >> Any suggestions / opinions?
> > >>
> > >> Best regards,
> > >>
> > >> Thomas
> > >> _______________________________________________
> > >> LLVM Developers mailing list
> > >> [hidden email]
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >
> > >
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev