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

Thomas Preudhomme via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 16 03:23:49 PDT 2018


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
<jh7370.2008 at my.bristol.ac.uk> 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-dev at lists.llvm.org> 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
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>


More information about the llvm-dev mailing list