Integer offset-based pool allocator transformation (Rawstack)

[rolfhm]

Introduce the rawstack transformation

The transformation inserts a stack variable of size (klon, stack_size[dtype][kind], kgpblock) into the driver for each of the types of temporary arrays with lead dimension klon encountered in the kernels. The stacks are then passed to the kernels along with their size where all the temporary arrays are allocated as calculated offsets stored in integers. Access to the temporary arrays are then calculated by offsets from the offset integers.

Assumes that all variables used for dimensions are available when entering the driver and that they are kept constant.

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (8e5c155) 92.33% compared to head (06f829b) 92.46%.

Files	Patch %	Lines
...sformations/transformations/raw_stack_allocator.py	99.11%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #201      +/-   ##
==========================================
+ Coverage   92.33%   92.46%   +0.12%     
==========================================
  Files          95       96       +1     
  Lines       17275    17616     +341     
==========================================
+ Hits        15951    16288     +337     
- Misses       1324     1328       +4     

Flag	Coverage Δ
lint_rules	96.22% <ø> (ø)
loki	92.32% <100.00%> (-0.01%)	⬇️
transformations	92.62% <99.11%> (+1.15%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rolfhm]

As I mentioned in the WP2 meeting, it can be limiting that all dimensions have to be known at the beginning of the the driver. In the acraneb2 dwarf, some of the arrays have dimension YDML_PHY_MF%YRPHY3%N_SPBAND, but this is set in PREPARE_ACRANEB2, which is called from the driver. One solution is to make the stacks allocatable and allocate right before the block loop and its pragmas. On the other hand, this is an artifact of the dwarf and I'm not sure we would find anything like it in the actual code.

[rolfhm]

It looks like this thing has some pretty serious conflicts now. Are they worth the effort to try to resolve?

[reuterbal]

Hi @rolfhm, thanks and apologies for taking so long with this. We are firmly committed to merging this development but are considering to integrate this with the existing pool allocator transformation. Therefore, we are possibly going to cherry-pick the code into a separate PR, I hope that's fine. So, I don't think there's a need to spend time on resolving conflicts for now.

[rolfhm]

OK, no problem. I'll leave it be until I hear something from you.

[reuterbal]

This has been merged with #314.