[ImportVerilog] Add support for string materialization #9112
Conversation
Scheremo
force-pushed
the
pr-string-const
branch
6 times, most recently
from
61842d6 to
06f396c
Compare
Scheremo
force-pushed
the
pr-string-const
branch
4 times, most recently
from
b26c580 to
5417a15
Compare
Scheremo
changed the title
| def LiteralStringConstantOp : MooreOp<"string_literal", [Pure]> { | ||
| let summary = "Produce a constant string value"; | ||
| let description = [{ | ||
| Produces a constant value of string type. | ||
|
|
||
| Example: | ||
| ```mlir | ||
| %0 = moore.string_literal "hello world" | ||
| ``` | ||
| }]; | ||
| let arguments = (ins StrAttr:$value); | ||
| let results = (outs StringType:$result); | ||
| let assemblyFormat = "$value attr-dict"; | ||
| } | ||
|
|
There was a problem hiding this comment.
Can we use the existing moore.string_constant for this, and then use a new moore.int_to_string cast to go from an integer to a !moore.string type? It would be good if we had just one way of materializing a string literal in the IR, which SV really wants to be an integer 😭. That can then be converted to a string, but use as an integer is also possible.
Strings are very annoying… on the one hand, I'd love to just have a moore.string_constant op that returns a !moore.string. But that makes it harder to convert the string to an integer when needed, since !moore.string is a dynamic string. So maybe sticking close to the SV spec with a string constant that produces and integer makes sense?
There was a problem hiding this comment.
I think no matter which way we pick it will feel bad 🙈
moore.int_to_string is a workable way; It just hurts to think we take a perfectly well-formed string, cast it to an int, and cast it back to a string 😭
Let's go for that solution for the moment though - I understand and agree with the concern of having a single way to handle StringLiteral expressions.
There was a problem hiding this comment.
Switched the lowering path to StringLiteral -> int -> StringType, even though it makes my eyes bleed a little bit 😅
There was a problem hiding this comment.
Yeah... this is pretty rough 🤣
Scheremo
force-pushed
the
pr-string-const
branch
3 times, most recently
from
2da86b6 to
9c44570
Compare
Extend ImportVerilog to lower SystemVerilog string constants by:
- Introducing `moore.int_to_string` to convert integer-backed literals to `!moore.string`.
- Materializing Slang string constants via a new `Context::materializeString` path.
- Integrating string handling into the general constant materialization flow.
- **Dialect**
- Add `IntToStringOp` (`moore.int_to_string`) to `MooreOps.td` with:
- `TwoValuedIntType` input -> `StringType` result
- **ImportVerilog conversion**
- Implement `Context::materializeString(constant, type, loc)`:
- Converts Slang `ConstantValue` string to an integer representation and creates a `moore.string_constant`, then wraps it with `moore.int_to_string`.
- Update `materializeConstant` to recognize `constant.isString()` and route to the new helper.
Scheremo
force-pushed
the
pr-string-const
branch
from
9c44570 to
97b6a7b
Compare
2 participants
Extend ImportVerilog to lower SystemVerilog string constants by:
Introducing
moore.int_to_stringto convert integer-backed literals to!moore.string.Materializing Slang string constants via a new
Context::materializeStringpath.Integrating string handling into the general constant materialization flow.
Dialect
IntToStringOp(moore.int_to_string) toMooreOps.tdwith:TwoValuedIntTypeinput ->StringTyperesultImportVerilog conversion
Context::materializeString(constant, type, loc):ConstantValuestring to an integer representation and creates amoore.string_constant, then wraps it withmoore.int_to_string.materializeConstantto recognizeconstant.isString()and route to the new helper.