Skip to content

Allow passing locks to C code.#288

Open
stephenneuendorffer wants to merge 1 commit intoXilinx:mainfrom
stephenneuendorffer:locks
Open

Allow passing locks to C code.#288
stephenneuendorffer wants to merge 1 commit intoXilinx:mainfrom
stephenneuendorffer:locks

Conversation

@stephenneuendorffer
Copy link
Collaborator

No description provided.

#include "kernel.h"

void func(int32_t *a, int32_t *b)
void func(int32_t *a, int32_t *b, int64_t lock)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bad for the carbon footprint to have 64 bits here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.. this is the main reason why this hasn't been checked in. Today, it's relatively easy to lower from locks to a constant 'index' type in MLIR, but the size of the index type is something 'implementation defined' (by default 64 bits). This really should be cleaner in the lowering to result in something more convenient.

%lock13_5 = AIE.lock(%tile13, 5) { sym_name = "output_lock" }

func.func private @func(%A: memref<256xi32>, %B: memref<256xi32>) -> ()
func.func private @func(%A: memref<256xi32>, %B: memref<256xi32>, %lock: index) -> ()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps index could be a more precise type depending on the architecture?
Or at least lowered to a more precise concrete type before calling the real AIE kernel?

@keryell
Copy link
Contributor

keryell commented Jul 20, 2023

To be merged?

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