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

LLVM Emitter: lam == entry_ || lam->is_basicblock() #108

Open
NeuralCoder3 opened this issue Oct 13, 2022 · 3 comments
Open

LLVM Emitter: lam == entry_ || lam->is_basicblock() #108

NeuralCoder3 opened this issue Oct 13, 2022 · 3 comments
Labels
bug Something isn't working

Comments

@NeuralCoder3
Copy link
Collaborator

NeuralCoder3 commented Oct 13, 2022

The assertion lam == entry_ || lam->is_basicblock() is thrown at unexpected points.

An example can be found here (LamSpec needs to be disabled from the optimizations to be able to run the code generation):
https://github.com/NeuralCoder3/thorin2/blob/c4326c6643b9e26777d0d7bd9b2f5dfc5ce1e885/enzyme/brussel.thorin

The problem instance in the linked file is caused when the brusselator_2d_loop function is external (otherwise it is completely deleted) and calls brusselator_f.

The body of brusselator_f seems to be irrelevant. But the error only occurs when brusselator_f is .extern.

Note: The error is also caused in other circumstances where brusselator_f is not marked with .extern but has a more complex body.

@NeuralCoder3 NeuralCoder3 added the bug Something isn't working label Oct 13, 2022
@NeuralCoder3
Copy link
Collaborator Author

The error especially also occurs/disappears in a version without .extern and with the original body
if line 170 is replaced with if_thenBf_149177 _149382.

@leissa
Copy link
Member

leissa commented Oct 13, 2022

In the end of the day it's duplicate of #9. If we end up with code that doesn't consist of top-level functions containing basic blocks, the LLVM backend cannot emit code - hence the assertion.

In this particular instance, the code generated by %affine.For is suboptimal as it should really make sure that after LowerAffineFor is done with it, everything should basically be a CFG. But in it's current state, it emits something "more fancy" that in simple cases the CopyProp is able to remove but in some more complex cases, the CopyProp will not do the trick.

@leissa
Copy link
Member

leissa commented Oct 13, 2022

So I guess, what I'm trying to say here is, that the real bug lies within LowerAffineFor. It should directly generate basic-block-like continuations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants