-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Sim] Flatten format string concatenations in canonicalizer #7316
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very nice! Minor comment regarding canonicalizers producing diagnostics.
if (!op.isFlat()) { | ||
// Get a new, flattened list of operands | ||
flatOperands.reserve(op.getNumOperands() + 4); | ||
auto isAcyclic = op.getFlattenedInputs(flatOperands); | ||
|
||
if (failed(isAcyclic)) { | ||
// Infinite recursion, but we cannot fail compilation right here (can we?) | ||
// so just emit a warning and bail out. | ||
op.emitWarning("Cyclic concatenation detected."); | ||
return failure(); | ||
} | ||
|
||
hasBeenFlattened = true; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we even have to emit diagnostics and handled failure cases here. I think the canonicalization is intended to be purely opportunistic, so if we encounter a cycle we should be able to just silently not canonicalize and return failure. Or in case getFlattenedInputs
creates a valid list of operands even if a cycle is present, we could just work with that and ignore the cycle altogether. Especially since the verifier catches this already 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is actually how I had done this originally. I then threw it out for a potentially silly reason: If we flatten despite the presence of cycles, it becomes difficult to test as it is hard to predict (and potentially unstable for future LLVM bumps?) which op is going to fail the verification first. And annoyingly I could not find any way to tell the -verify-diagnostics
framework that the error may be produced at different locations. Quite possibly I'm overthinking this (I usually do). But in the end I decided to just keep it as simple as possible, given that:
- A cyclic concatenation would almost certainly be indicative of a bug in the frontend.
- It is pretty much guaranteed to cause a failure in the subsequent lowering pass.
I kept the warning in case something goes wrong and the cycle causes an infinite loop, so it doesn't just freeze quietly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense! Very cool stuff in any case 😎 🥳!
Provide an interface to get the flat format string for
sim.fmt.concat
operations and opportunistically flatten during canonicalization.CC #7292