Skip to content
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

Merged
merged 2 commits into from
Jul 16, 2024

Conversation

fzi-hielscher
Copy link
Contributor

Provide an interface to get the flat format string for sim.fmt.concat operations and opportunistically flatten during canonicalization.

CC #7292

Copy link
Contributor

@fabianschuiki fabianschuiki left a 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.

Comment on lines +271 to +284
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;
}
Copy link
Contributor

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 😃

Copy link
Contributor Author

@fzi-hielscher fzi-hielscher Jul 15, 2024

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.

Copy link
Contributor

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 😎 🥳!

@fzi-hielscher fzi-hielscher merged commit 911988f into llvm:main Jul 16, 2024
4 checks passed
@fzi-hielscher fzi-hielscher deleted the fmt-concat-flatten branch July 16, 2024 20:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants