Add string literal support in constant folding.

[fruffy]

String literals can also be compared and folded if they are equal or unequal. There might be more cases but I think the changes include the major ones.

[asl]

Can this be simplified to:

} else if (const auto *left = eleft->to<IR::StringLiteral>()) {
..

This would skip double cast. The code for BoolLiteral likely would need to be fixed as well :)

[asl]

Also, maybe it would help to add comment to bool eqTest above to clarify that compare is called only for IR::Equ and IR::Neq, so other cases are not possible. It tool me a while to figure out why other IR::Operation_Binary cases are not handled...

[vlstill]

Fun thing, P4 spec says there are no operations on string literals... What is the use case for comparing strings btw?

[fruffy]

Fun thing, P4 spec says there are no operations on string literals...

Hmm, in many cases the compiler optimization passes have more flexibility than what the spec permits, under the assumption that user-facing behavior is not affected.

However, in this case, because ConstantFolding is run before type-checking it could be possible that comparing two string literals could lead to a violation. In the sense that a technically invalid program is not rejected (e.g., an action with a bool parameter and an input like "a" == "b"). I assume this parses just fine.

What is the use case for comparing strings btw?

This is quite useful when working with IR expressions (often generated for static/dynamic analysis). For example, simplifying an expression of the from:
"table_action_drop" = "table_action_pass" ? 1 : 0 to 0.

ConstantFolding and StrengthReduction are both useful for simplifying large, complex expressions because they are self-contained and do not require a type or reference map.

Maybe it makes sense to split ConstantFolding into a minimal, spec-complaint version and a rich, self-contained version that performs simplifications as aggressively as possible.

[vlstill]

Oh, I see, this is for P4Tools etc. not for actually using it in user-written P4 code.

Maybe it makes sense to split ConstantFolding into a minimal, spec-complaint version and a rich, self-contained version that performs simplifications as aggressively as possible.

Maybe... the difference will be really probably (hopefully) just this.

I'd say that ideally, we would want to type-check the program as one of the very first things, before constant folding. That would require ability to constant-evaluate expressions from the type checker (but I'd guess they would/could be type-checked at the point when they are evaluated!). But rewriting the type checker would be a huge thing. That would even allow constant-folding to be deferred to midend, where it belongs.