Skip to content

Add Op registration to symbol table inside OpBuilder #4

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

Open
wants to merge 80 commits into
base: next
Choose a base branch
from

Conversation

lima-limon-inc
Copy link

@lima-limon-inc lima-limon-inc commented May 19, 2025

Closes issue number 404

Currently, building an operation and adding it to a symbol table are done separately. This PR makes operation insertion into a symbol table happen inside the Operation Builder, thus encapsulating it with Operation creation.

To enable it, a new trait BelongsInSymbolTable was created. Operations that have this trait are going to be stored inside the symbol table of a different operation.

This meant that these operations needed a reference to their parent's symbol table at operation creation. To support this,
a new OpCreateParamTypevariant was created called BuildOnlyParameter. This is used for arguments that are only used in the Operation::creation and OperationBuilder functions, in this case a reference to the caller'sSymbolTable.

Besides the addition of a new function parameter, the #[operation] macro was expanded to handle Symbol Table insertion.

Originally, Operations were built, verified and returned inside the BuildOp::to_tokens macro.
However, adding conditional symbol-table insertion made the macro a bit too convoluted (see here).
So in order to make the flow more consistent and easier to follow, I went for splitting the macro up into 3 different stages:
BuildOp, ModifyOp and ReturnOp

  • BuildOp was basically unchanged. The only change was that it now doesn't return the built op, it only builds it and stores it in a variable.
  • ModifyOp was created and is the place where the conditional symbol-table insertion logic resides. This is also "extensible", other post-build functions can be inserted inside it and should be able to simply "chain" their functionality. It can be seen as a "post build hook".
  • ResultOp: This last macro is simply in charge of returning the op. I added an #[allow(dead_code)] simply to keep all the *Op macros in the same format

…ctly but is only debug

Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
…row checker issues

Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Comment on lines 267 to 288
Some(OperationFieldType::Jamon) => {
// std::dbg!("MANTECA MANTECA");
// std::dbg!(&field_ty);
create_params.push(OpCreateParam {
param_ty: OpCreateParamType::CustomField(field_name.clone(), field_ty),
r#default: field.attrs.default.is_present(),
});
// TODO: Remove from fields, only used when building
named_fields.push(syn::Field {
attrs: field.attrs.forwarded,
vis: field.vis,
mutability: syn::FieldMutability::None,
ident: Some(field_name.clone()),
colon_token: Some(syn::token::Colon(field_span)),
ty: field.ty,
});
self.parent_jamon = Some(OpJamon {
name: field_name,
// span: field_span,
});
// continue;
}
Copy link
Author

Choose a reason for hiding this comment

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

Not used currently, left just in case

@lima-limon-inc lima-limon-inc force-pushed the fabrizioorsi/op-builder-symbol-table branch from 7a10a92 to 7a395a5 Compare May 22, 2025 13:56
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Signed-off-by: Tomas Fabrizio Orsi <[email protected]>
Comment on lines 1 to 12
public builtin.function @test(v0: u32, v1: u32) -> u32 {
^block0(v0: u32, v1: u32):
^block1(v0: u32, v1: u32):
v2 = scf.index_switch v0 : u32
case 0 {
^block1:
^block2:
v3 = arith.constant 0 : u32;
scf.yield v3;
}
default {
^block2:
^block3:
v4 = arith.mul v0, v1 : u32 #[overflow = checked];
scf.yield v4;
Copy link
Author

Choose a reason for hiding this comment

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

These tests got updated because now they contain a WorldBuilder which wasn't there before. The only thing that (should)'ve changed is the block number (which increased by one).

@lima-limon-inc lima-limon-inc force-pushed the fabrizioorsi/op-builder-symbol-table branch from e019ae7 to 7c38701 Compare May 26, 2025 20:46
@lima-limon-inc lima-limon-inc force-pushed the fabrizioorsi/op-builder-symbol-table branch from 2bbcc9f to e224ec1 Compare May 27, 2025 13:09
@lima-limon-inc lima-limon-inc force-pushed the fabrizioorsi/op-builder-symbol-table branch from 0cdb2b0 to 50e8faa Compare May 27, 2025 15:18
@lima-limon-inc
Copy link
Author

Edit: I removed the struct SymbolTableHolder in favor of the already present World. It added a too much import related complexity for the little value it added.

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.

1 participant