This is an archive of the discontinued LLVM Phabricator instance.

[Flang][OpenMP] Add lowering from PFT to new MapEntry and Bounds operations and tie them to relevant Target operations
ClosedPublic

Authored by agozillon on Aug 24 2023, 6:59 AM.

Details

Summary

This patch builds on top of a prior patch in review which adds a new map
and bounds operation by modifying the OpenMP PFT lowering to support
these operations and generate them from the PFT.

A significant amount of the support for the Bounds operation is borrowed
from OpenACC's own current implementation and lowering, just ported
over to OpenMP.

The patch also adds very preliminary/initial support for lowering to
a new Capture attribute, which is stored on the new Map Operation,
which helps the later lowering from OpenMP -> LLVM IR by indicating
how a map argument should be handled. This capture type will
influence how a map argument is accessed on device and passed by
the host (different load/store handling etc.). It is reflective of a
similar piece of information stored in the Clang AST which performs a
similar role.

As well as some minor adjustments to how the map type (map bitshift
which dictates to the runtime how it should handle an argument) is
generated to further support more use-cases for future patches that
build on this work.

Finally it adds the map entry operation creation and tying it to the relevant
target operations as well as the addition of some new tests and alteration
of previous tests to support the new changes.

Depends on https://reviews.llvm.org/D158732

Diff Detail

Event Timeline

agozillon created this revision.Aug 24 2023, 6:59 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
agozillon requested review of this revision.Aug 24 2023, 6:59 AM

Patch 2/4 of the map changes from the patch series made by: https://reviews.llvm.org/D158732, https://reviews.llvm.org/D158735, https://reviews.llvm.org/D158737 and https://reviews.llvm.org/D158734 that aims to expand the current map support of the OpenMP dialect and lower from Fortran -> MLIR -> LLVM IR, future support on expanding the lowering from the OpenMP dialect to LLVM IR for map on TargetOp (omp target) will be forthcoming for declare target and explicit map variables hopefully in the near future (implicit likely a little while after that).

This patch should not pass CI on its own, patch 4: https://reviews.llvm.org/D158737, should pass provided the dependencies are setup correctly.

A small ping for some attention on this patch if a reviewer can spare some time, thank you very much!

I see a lot of copy-paste code from the OpenACC lowering. I don't think this code duplication is what we want. It should be shared whenever possible.

flang/lib/Lower/OpenMP.cpp
1744–1769

This seems copy-paste from the OpenACC part. Wouldn't it makes more sense to reuse it?

1747

Same here.

clementval requested changes to this revision.Aug 31 2023, 11:36 AM
This revision now requires changes to proceed.Aug 31 2023, 11:36 AM

I agree with Valentin that it looks like there's some opportunity to share the lowering. For the atomic lowering work which I am in the process of uploading, I shared the lowering by creating a new header file in flang/lib/Lower/DirectivesCommon.h and then template specializing where needed.

flang/lib/Lower/OpenMP.cpp
1850

comaprison -> comparison
abiltiy -> ability

I agree with Valentin that it looks like there's some opportunity to share the lowering. For the atomic lowering work which I am in the process of uploading, I shared the lowering by creating a new header file in flang/lib/Lower/DirectivesCommon.h and then template specializing where needed.

Thank you very much for the pointer! In this case did you mean flang/include/Lower/DirectivesCommon.h? I can move the shared functionality here, unless you wish me to wait until your patch lands so as not to get in the way of your atomic work?

flang/lib/Lower/OpenMP.cpp
1744–1769

Yes both segments are verbatim from OpenACC at the moment (so thank you very much to the OpenACC members involved), I'm happy to place them somewhere shared between both OpenACC and OpenMP.

My main hesitation to do that at first was not knowing if alterations to the implementation specific to OpenMP would be required. However, I can't really think of any cases where it would be required at this point and I imagine specialisation of some kind if it's a template as @razvanlupusoru suggests would be possible or just separating it out again if that fails is fine.

So I am happy to make this change if that's what we wish!

I agree with Valentin that it looks like there's some opportunity to share the lowering. For the atomic lowering work which I am in the process of uploading, I shared the lowering by creating a new header file in flang/lib/Lower/DirectivesCommon.h and then template specializing where needed.

Thank you very much for the pointer! In this case did you mean flang/include/Lower/DirectivesCommon.h? I can move the shared functionality here, unless you wish me to wait until your patch lands so as not to get in the way of your atomic work?

Since the code is likely to not be templated we can put it in a .cpp file.

flang/lib/Lower/OpenMP.cpp
1744–1769

Everything that gather bounds information is just pure parse tree related so there should be no divergence between OpenACC and OpenMP.

agozillon marked an inline comment as done.EditedSep 4 2023, 11:41 AM

I agree with Valentin that it looks like there's some opportunity to share the lowering. For the atomic lowering work which I am in the process of uploading, I shared the lowering by creating a new header file in flang/lib/Lower/DirectivesCommon.h and then template specializing where needed.

Thank you very much for the pointer! In this case did you mean flang/include/Lower/DirectivesCommon.h? I can move the shared functionality here, unless you wish me to wait until your patch lands so as not to get in the way of your atomic work?

Since the code is likely to not be templated we can put it in a .cpp file.

I think it may be necessary to template it to pass in the correct operation type to the builders create operation, e.g. builder.create<mlir::omp::DataBoundsOp> vs builder.create<mlir::acc::DataBoundsOp>, at least to just lift the existing implementation it's the easiest way of doing it I imagine.

An alternative I can think of is having a wrapper lambda for the create function defined by the OpenMP/OpenACC implementation and pass that in.

OmpObject vs AccObject likely need templated on (although perhaps there's a shared node type I'm unaware of), but the omp::DataBoundType and acc::DataBoundType perhaps don't need to be as you can likely pass these in as an argument.

There's most likely easier options that I'm overlooking here, so if you have a better idea or prefer one over the other, please do mention it!

I agree with Valentin that it looks like there's some opportunity to share the lowering. For the atomic lowering work which I am in the process of uploading, I shared the lowering by creating a new header file in flang/lib/Lower/DirectivesCommon.h and then template specializing where needed.

Thank you very much for the pointer! In this case did you mean flang/include/Lower/DirectivesCommon.h? I can move the shared functionality here, unless you wish me to wait until your patch lands so as not to get in the way of your atomic work?

Since the code is likely to not be templated we can put it in a .cpp file.

I think it may be necessary to template it to pass in the correct operation type to the builders create operation, e.g. builder.create<mlir::omp::DataBoundsOp> vs builder.create<mlir::acc::DataBoundsOp>, at least to just lift the existing implementation it's the easiest way of doing it I imagine.

An alternative I can think of is having a wrapper lambda for the create function defined by the OpenMP/OpenACC implementation and pass that in.

OmpObject vs AccObject likely need templated on (although perhaps there's a shared node type I'm unaware of), but the omp::DataBoundType and acc::DataBoundType perhaps don't need to be as you can likely pass these in as an argument.

There's most likely easier options that I'm overlooking here, so if you have a better idea or prefer one over the other, please do mention it!

These functions do not require any template so they can be in the .cpp file. Please use template only for what is necessary.

genBoundsOpsFromBox
genBaseBoundsOps
getDataOperandBaseAddr
gatherDataOperandAddrAndBounds
agozillon updated this revision to Diff 555784.Sep 4 2023, 6:22 PM

update and squash

agozillon added a comment.EditedSep 4 2023, 6:35 PM

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Alternatively (and in hindsight), I imagine having an enum containing values for OpenMP/OpenACC (enum in-case other dialects have their own BoundsOp and for a little more description than a boolean) and passing that in as an argument and then calling the appropriate if would probably suffice as well for the moment.

Please do let me know which you'd prefer or if you have an alternative in mind.

I am mostly OK with this change and I accept it :) - except one piece. The only part I am not comfortable with is the isCapturedByRef - I would prefer this analysis to be moved out of lowering. And more thought to be given how to make it flang specific instead of clang specific.

flang/lib/Lower/OpenMP.cpp
1743

Seems OK to remove.

1754

I took a closer look at this routine and I think this is probably the main part I am not sure about.

It all stems from the table copied from clang - it uses scalar, aggregate, and pointer terminology - but it is not immediately clear how this applies to Fortran. Are arrays considered aggregates? What about descriptors which point to the data and the data pointer itself? What about Fortran pointers (which use descriptor)?

To be honest, I also find clang's implementation a bit weird and I noticed you used the same isByRef initialized to true, and then try to prove/disprove as you go along. To me it feels that isByRef should always be safe and thus it makes sense it is default. Then the rest of the code should look for optimizing where it needs to pass by value.

Also, I would suggest to implement this in a follow-up pass instead of doing it in lowering. Namely, always create map-entry operations that pass by reference (and thus require a reference type), then optimize to pass by value. Doing it at MLIR level you would also be able to check for parent data mapping operations.

agozillon added inline comments.Sep 7 2023, 8:59 AM
flang/lib/Lower/OpenMP.cpp
1754

I took a closer look at this routine and I think this is probably the main part I am not sure about.

It all stems from the table copied from clang - it uses scalar, aggregate, and pointer terminology - but it is not immediately clear how this applies to Fortran. Are arrays considered aggregates? What about descriptors which point to the data and the data pointer itself? What about Fortran pointers (which use descriptor)?

You are correct, It is indeed taken from Clang, but it's more as a reference guide for somewhere to start that can be specialized, and gives some context to the concept behind the function (which is how various OpenMP clauses affect the capture semantics of variables as described in the OpenMP specifications data mapping and attribute rules and clauses section), rather than something to strictly copy, as I am aware there's going to be a fair few distinct differences between the two languages and some of these should be defined within the specification.

As for the terminology yes, it is indeed C/C++ specific, but I believe the semantics of a lot of the types and how they are eventually lowered to LLVM-IR and interact with the OpenMP runtime remain e.g. derived types can be considered aggregates to some extent, scalars are equivalent to a lot of base Fortran data types (real/integer), arrays can be devolved to pointers (more so the C/C++ style pointer than Fortran pointers), you do start to deviate when you get to Fortran's pointers and descriptors however as they become more like "aggregates" as they devolve to structures when lowered to LLVM-IR it seems, but where they deviate it can be built upon.

To be honest, I also find clang's implementation a bit weird and I noticed you used the same isByRef initialized to true, and then try to prove/disprove as you go along. To me it feels that isByRef should always be safe and thus it makes sense it is default. Then the rest of the code should look for optimizing where it needs to pass by value.

True, It's always safe in the sense that the code will likely always work in some way, but I believe the semantics will not necessarily be as prescribed by the specification. So all this function is (attempting at least as it's not fully implemented) doing as you say, is setting things to byref by default and in certain cases where the specification does not allow for it, it will change the copy semantics. However, it is fairly barebones at the moment.

Also, I would suggest to implement this in a follow-up pass instead of doing it in lowering. Namely, always create map-entry operations that pass by reference (and thus require a reference type), then optimize to pass by value. Doing it at MLIR level you would also be able to check for parent data mapping operations.

I would be happy to do this in an optimisation pass if you think that's a better direction. My main thoughts in having it here was that we would know the semantics we intend to use as early as possible so subsequent parts of the lowering could utilise it if necessary (nothing does at the moment, nor do I have any idea on what would at the moment, so I'm probably being a little too cautious in this aspect), and we would have more access to Fortran specific information here, as opposed to in MLIR where we may lose some of it (although, looking through clauses in MLIR is likely significantly easier than during the lowering I agree, but that might just be me still being terrible at traversing the Fortran PFT :) ).

If we're not comfortable with this function for the patch I can remove it from the patch at the moment and have the default for now be set to byref for explicit maps, and in the future when I revisit this I can make it an optimisation pass that occurs after lowering. So please do let me know if that is your preference?

As an aside on a future related patch, I have an intention to do some form of transformation to move implicit captures into map capture clauses alongside the explicit maps, they'll be ByCopy by default as opposed to ByRef. The intent is to to make future optimisations and the lowering from OpenMP dialect -> LLVM-IR easier and the mapping relationship more explicit in the MLIR. Would you prefer/suggest this to be after the lowering in an optimisation pass or during the lowering (slightly after the target region has been lowered)? I have a variation of both so it's not a big deal to select one or the other (same reasoning for having it in the initial PFT lowering), I ask as your feedback has been much appreciated so far and it may save some iterations in the future patch! :)

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

I could also just create an enum with values for OpenMP/OpenACC and pass it in as an argument to the functions and based on the enum call the appropriate create operation, should also avoid the templatization and the need for the create function. If that is preferable?

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

I could also just create an enum with values for OpenMP/OpenACC and pass it in as an argument to the functions and based on the enum call the appropriate create operation, should also avoid the templatization and the need for the create function. If that is preferable?

I think the template is cleaner. In the end each function will be instantiated only twice so it should add a too big overhead in build time.

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

I could also just create an enum with values for OpenMP/OpenACC and pass it in as an argument to the functions and based on the enum call the appropriate create operation, should also avoid the templatization and the need for the create function. If that is preferable?

I think the template is cleaner. In the end each function will be instantiated only twice so it should add a too big overhead in build time.

Sounds good, I will wait until tomorrow to make adjustments to the patches in-case of any other feedback/replies!

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

I could also just create an enum with values for OpenMP/OpenACC and pass it in as an argument to the functions and based on the enum call the appropriate create operation, should also avoid the templatization and the need for the create function. If that is preferable?

I think the template is cleaner. In the end each function will be instantiated only twice so it should add a too big overhead in build time.

Sounds good, I will wait until tomorrow to make adjustments to the patches in-case of any other feedback/replies!

Thanks! And sorry again for the extra work.

Also note that there is a known issue with the stride computation for N-dimensional array where N > 1. I'm planning to work on that soon but this does not impact this patch. Just wanted to make you aware of this current issue.

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

I could also just create an enum with values for OpenMP/OpenACC and pass it in as an argument to the functions and based on the enum call the appropriate create operation, should also avoid the templatization and the need for the create function. If that is preferable?

I think the template is cleaner. In the end each function will be instantiated only twice so it should add a too big overhead in build time.

Sounds good, I will wait until tomorrow to make adjustments to the patches in-case of any other feedback/replies!

Thanks! And sorry again for the extra work.

It's not a problem, always happy to try do what's best for the community/project

Also note that there is a known issue with the stride computation for N-dimensional array where N > 1. I'm planning to work on that soon but this does not impact this patch. Just wanted to make you aware of this current issue.

thank you for the notice! Shouldn't be a problem for the lowering I have in place at the moment either, as I've only set it up to handle 1-D array sectioning for the moment with constants, a lot of expanding on it is still required.

Thank you!

flang/lib/Lower/OpenMP.cpp
1754

If we're not comfortable with this function for the patch I can remove it from the patch at the moment and have the default for now be set to byref for explicit maps, and in the future when I revisit this I can make it an optimisation pass that occurs after lowering. So please do let me know if that is your preference?

Yes :)

As an aside on a future related patch, I have an intention to do some form of transformation to move implicit captures into map capture clauses alongside the explicit maps, they'll be ByCopy by default as opposed to ByRef. The intent is to to make future optimisations and the lowering from OpenMP dialect -> LLVM-IR easier and the mapping relationship more explicit in the MLIR. Would you prefer/suggest this to be after the lowering in an optimisation pass or during the lowering (slightly after the target region has been lowered)? I have a variation of both so it's not a big deal to select one or the other (same reasoning for having it in the initial PFT lowering), I ask as your feedback has been much appreciated so far and it may save some iterations in the future patch! :)

I would prefer for it to be after lowering if possible. That is the design I had in mind for OpenACC implicit data clauses. We can discuss later if there are cases that cannot be handled due to loss of info - in such instances I personally would prefer for FE to simply insert a placeholder that captures appropriate info that can later be filled in by the pass.

agozillon added inline comments.Sep 7 2023, 4:23 PM
flang/lib/Lower/OpenMP.cpp
1754

Sounds good, I'll try to get this series of patches updated for tomorrow!

And that's an interesting and useful solution for me to keep in mind for the future in-case we run into that issue thank you! But yes, if we run into that situation I'll open an RFC on it or a more general forum/slack post to discuss it in a bit more depth. I'll make the implicit data clauses gathering an optimisation pass then and we'll see how it goes as we progress :-)

Thank you very much for your help and input so far.

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

I could also just create an enum with values for OpenMP/OpenACC and pass it in as an argument to the functions and based on the enum call the appropriate create operation, should also avoid the templatization and the need for the create function. If that is preferable?

I think the template is cleaner. In the end each function will be instantiated only twice so it should add a too big overhead in build time.

Sounds good, I will wait until tomorrow to make adjustments to the patches in-case of any other feedback/replies!

It seems we used a slightly different approach on the DirectivesCommon files. I wanted to point it out that I decided to put everything in a header file.
Please see this (it is a bit outdated - I have a new one I am uploading in a bit to github instead): https://reviews.llvm.org/D158772
I had decided to just use a DirectivesCommon.h file with templates and implementation directly in header so that it can be directly instantiated at use site - by putting it in a source file, you have to manually template instantiate which will be resolved at link time.
That said, I decided to move my DirectivesCommon.h to include folder so that it more closely matches your code here. I will upload a copy with it soon.
So your technique here will still work to have the declarations in header and implementation in source file.

The last update moved the functions into the shared files DirectivesCommon.h/DirectivesCommon.cpp, I did my best to limit the amount of templates, the only template is a helper function that wraps the create call for the omp/acc DataBoundsOp. Perhaps with a shared interface in the future it could be removed.

Thanks for trying to limit the template. On a second thoughts I think it'll be easier to templatized these functions instead of passing this create function. Sorry for the wrong pointer.

I could also just create an enum with values for OpenMP/OpenACC and pass it in as an argument to the functions and based on the enum call the appropriate create operation, should also avoid the templatization and the need for the create function. If that is preferable?

I think the template is cleaner. In the end each function will be instantiated only twice so it should add a too big overhead in build time.

Sounds good, I will wait until tomorrow to make adjustments to the patches in-case of any other feedback/replies!

It seems we used a slightly different approach on the DirectivesCommon files. I wanted to point it out that I decided to put everything in a header file.
Please see this (it is a bit outdated - I have a new one I am uploading in a bit to github instead): https://reviews.llvm.org/D158772
I had decided to just use a DirectivesCommon.h file with templates and implementation directly in header so that it can be directly instantiated at use site - by putting it in a source file, you have to manually template instantiate which will be resolved at link time.
That said, I decided to move my DirectivesCommon.h to include folder so that it more closely matches your code here. I will upload a copy with it soon.
So your technique here will still work to have the declarations in header and implementation in source file.

It's no problem, I can move it all into the header file as I'm going to up-date this patch to utilise templates soon as requested by @clementval, and I can move DirectivesCommon.h into Lib/Lower if you'd prefer to keep it the way you have currently in your patch?

agozillon updated this revision to Diff 556308.Sep 8 2023, 3:12 PM

Adding most recent review comments, move to templates, remove function for later addition as an optimisation pass, and move DirectiveCommons.h

I've removed the offending function for now, swapped to utilising templates in the DirectivesCommon.h header now and modified it to just be a header file that now resides inside of the Lib/Lower folder alongside OpenMP.cpp/OpenACC.cpp.

In the other segment of the patch I've also changed the parsing and printing of the MLIR map_entries and related target operations, so that the map_entries are the only place the map clauses tofrom/from etc. are shown (and no longer is there a numeric value for it), the whole array of bitfield values are also printed. I have updated the affected tests across the patch series as well.

Hopefully, these changes make the patch series a little more reasonable! :-) I would appreciate if you could re-accept or accept for the first time if you're happy with the patches as they are now, if not please do add further feedback.

razvanlupusoru accepted this revision.Sep 11 2023, 8:15 AM

Looks good to me! Thank you!

@razvanlupusoru @clementval thank you both very much for your reviews!

@clementval if you're happy with this patch would it please be possible to also get an acceptance from you? Or further feedback points if you think more needs to be done of course!

If I get both acceptances I will leave the patch series open until Thursday to give time for further comments/feedback from other reviewers (in particular @kiranchandramohan and @jsjodin) at that point if no further comments/change requests are received I will push it upstream!

This revision is now accepted and ready to land.Sep 13 2023, 8:54 PM
agozillon updated this revision to Diff 556778.Sep 14 2023, 5:51 AM

Remove the map flag changes from the initial PFT lowering (it's now in the later LLVM-IR lowering stage in the declare target patch instead), fix tests to reflect maptype changes and name change of operations

LGTM

Thank you very much!

TIFitis accepted this revision.Sep 18 2023, 5:20 AM

Is there a test for a slice of an assumed shape array?

Also, could you check if we take a slice of an array and pass it to a function that accepts an assumed shape arrray and then further take a section of it in the map clause, whether it works correctly?

flang/test/Lower/OpenMP/target.f90
288

The check lines should not have MLIR hardcoded values. We can either ignore them if it is not important. If it is important it should be captured in a variable.

Is there a test for a slice of an assumed shape array?

I don't think there is, just fixed size arrays, I can try to add the below requested test and it should cover this case as well.

Also, could you check if we take a slice of an array and pass it to a function that accepts an assumed shape arrray and then further take a section of it in the map clause, whether it works correctly?

That's an interesting test and one I'd be happy to check, I think I might add a seperate test file for this and for other future tests relating to bounds information generation.

flang/test/Lower/OpenMP/target.f90
288

Happy to update the test, I am leaning more towards capturing this particular value, but I'll see when I look closer.

agozillon updated this revision to Diff 556990.Sep 18 2023, 8:09 PM

fixing lost segment of patch from last rebase, rebasing again and adding addiitonal tests relating to array slicing and sectioning, alongside removing checkMapType from proccessMap as the lowering from box types is now supported to some extent.

Most recent series of updates was a rebase, a revert of a test change I made requested by @TIFitis, the minor tweak of a test and the addition of the requested array slice+sectioning test from @kiranchandramohan.

The latter required some further extension of the early outlining pass (bit of a shame as we might end up getting rid of it soon, provided the move to IsolatedFromAbove is succesful, but for now it's maintenance is required) to support box types and multi-return MLIR SSAs a little better, but it resulted in some refactoring as well so it's a little cleaner I think and helps support anything that uses box types (pointer/allocatables as an example). Lowering this type of test also required the removal of the processMap functions checkType, which primarily blocked lowering of box types and pointers, which the lowering from PFT -> MLIR would now be supported in a reasonable initial capacity (albeit the lowering to LLVM-IR and beyond is still forthcoming in the next patch series).

I need to see if the rebase went through nicely this time and https://reviews.llvm.org/D158737 passes the buldbots. However, If you're happy with the most recent additions and the patch series in general I'd love a final acceptance @kiranchandramohan if you think it's ready to land, and then I could do so later today, unless you wish to give a couple of days leeway for other reviewers to have a final lookover it.

Thanks. LG.

Thanks. LG.

Thank you for the review and help!

It looks like the buildbot in https://reviews.llvm.org/D158737 is happy and every patch in the series has been accepted. It seems this series is ready to land, so I'll do so in the next hour!