TableGen 'code' type to be eliminated

We are seriously considering eliminating the 'code' type from TableGen. The 'code' type is used to represent code sequences, which are specified with the [{ ... }] brackets. The bracket syntax will be retained, but the type distinction will be eliminated.

A code sequence is stored as a string, but with the type of 'code'. Some string operations, such as the paste operator (#), work on code, too. But other operations, such as !strconcat and !eq, do not. There does not appear to be any reason to maintain the distinction between string and code, except when formatting the value of a field. We will retain the two formats "..." and [{...}] when printing a field value.

I have checked all the TableGen backends and none appear to make any semantic distinction between strings and code.

Well, it is not semantically different but having “code” in .td files does make the files readble to me, at least. It distinctly tells me that the value of the field is a C++ code which needs to be grammatically correct. This extra semantics associated with “code” is appealing for readibility.

Well, it is not semantically different but having "code" in .td files does make the files readble to me, at least. It distinctly tells me that the value of the field is a C++ code which needs to be grammatically correct. This extra semantics associated with "code" is appealing for readibility.

+1 to this -- we use `code` in Attr.td (for instance) to distinguish
between arbitrary string data and data that is intended to have some
valid syntax (whether it's C++ or otherwise) that will be checked
elsewhere. It wouldn't be the end of the world to lose the clarity
there, but it also doesn't seem like there's a large maintenance
burden to continuing to support it either (unless I'm missing
something).

~Aaron

I agree. We will retain the distinct code brackets, both in the source files and when printing code fields in records.

What is the motivation to deprecate the type though?

The initial motivation was to make it easier for the all the string bang operators (e.g., !strconcat, !eq, !interleave) to support code. But then I started looking around and noticed that very few backends care about the distinction. In fact, for at least half the backends, they are checking for both StringInit and CodeInit and treating them the same.

Then I searched all the .td files for !cast<code>. There are no occurrences.

So it appears to be a nice simplification for TableGen, additional flexibility for .td files, and a positive change for backends.

Would it be possible to keep “code” in the TableGen syntax as an alias for “string” while removing the distinction in TableGen backends? That would retain the documentation benefits of “code” in .td files. TBH, this is how I thought “code” and “string” already worked; I wasn’t aware of the distinction.

Yes, my plan is to keep the reserved word 'code' as a synonym for 'string', and to continue printing code with the [{...}] brackets.

Yes, my plan is to keep the reserved word 'code' as a synonym for 'string', and to continue printing code with the [{...}] brackets.

That'd work fine by me then, thanks!

~Aaron