-
Notifications
You must be signed in to change notification settings - Fork 114
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
[WIP] LLVM rebasing efforts #359
Conversation
37a3c67
to
ae7fcb2
Compare
lib/polygeist/Ops.cpp
Outdated
@@ -5778,6 +5778,10 @@ LogicalResult fixupGetFunc(LLVM::CallOp op, OpBuilder &rewriter, | |||
|
|||
Value pval = op.getOperand(0); | |||
|
|||
// We can't get type info from opaque pointer which we now use TODO what do we |
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.
Can you take a look at what we should be doing here instead?
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.
Most of the remaining failing tests are related to this
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.
in LLVM itself there is a getFunctionType from the CallInst.
we should use the MLIR-equivalent of that here to get FT
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.
LLVM: https://llvm.org/doxygen/InstrTypes_8h_source.html#l01270
I don't immediately see anything upstream MLIR that does the LLVM similar. @ftynse if you know offhand
If not we may need to add support to upstream MLIR for
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 think the assumption so far was that functions are non-variadic so the function type can be trivially reconstructed from the lists of operands and results of the call op. For variadic functions, there's a FIXME just above: https://github.com/llvm/llvm-project/blob/b300f8c89829f920102e6ec5acc7d1b134bcff75/mlir/include/mlir/Dialect/LLVMIR/LLVMOps.td#L584-L586
@wsmoses I think this is now ready? This also contains the changes in #355, (If they look good) I will squash in two different commits I think, one for the previous pr, and one for this. |
fe46ab4
to
eb83799
Compare
668cfba
to
b4c1029
Compare
* More flexible specification of coarsening factors * Fix device-side get_global ops * For PGO Output the accumulated runtime of kernels, not individual * Allow for granular blcok coarsening factors * Various GPU bug fixes * Remove unneeded kernels from the gpu binary * Collect kernel statistics * Add polygeist::UndefOp for cases when the type is not LLVM::
(merge 65fa61d)
b4c1029
to
9be12f8
Compare
(This is on top of #355)
WIP PR for rebasing to latest llvm-project.
As llvm deprecated typed pointers we would need to eventually remove all usage of them in Polygeist as well if my understanding is correct.
Another big part that is affected by the removal of typed llvm pointers is the AST->MLIR frontend (cgeist).
The LLVM dialect code-gen there is mostly unused as it was for ABI compatibility issues we have mostly solved.
So I would say we should remove all usage of the LLVM dialect (except the struct and array types) in the frontend while doing the rebase to make our lives easier. This might require some new additions to the polygeist dialect.