Skip to content

Remove grant_always#99

Merged
2 commits merged intocoredac:mainfrom
ShangkunLi:remove-grant-always
Jul 31, 2025
Merged

Remove grant_always#99
2 commits merged intocoredac:mainfrom
ShangkunLi:remove-grant-always

Conversation

@ShangkunLi
Copy link
Copy Markdown
Collaborator

In this pr:

  • Remove the grant_always operations in --transform-ctrl-to-data-pass
  • After removing the grant_always, we can achive CompiledII = 6 : i32, RecMII = 4 : i32, ResMII = 2 : i32 for branch_for.mlir (previous compiledII=7) and CompiledII = 3 : i32, RecMII = 3 : i32, ResMII = 2 : i32 for simpleloop.mlir (previous compiledII=5).

@ShangkunLi ShangkunLi requested a review from tancheng July 29, 2025 07:44
@ShangkunLi ShangkunLi marked this pull request as ready for review July 29, 2025 07:44
Copy link
Copy Markdown
Contributor

@tancheng tancheng left a comment

Choose a reason for hiding this comment

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

Hmm, can this constant binding be done in FusePatternsPass.cpp?

@ShangkunLi
Copy link
Copy Markdown
Collaborator Author

Hmm, can this constant binding be done in FusePatternsPass.cpp?

I didn't add the constant binding feature in this pr yet. And I creates a single --fuse-constant-and-grant-once for the constant binding. Because the ideal flow of fusion is:

Fuse constant and grant_once -> fuse control flow related operations (e.g., loop control related operations) -> fuse computation related operations (e.g., add-mul, add-add, etc.).

Since I need the ir with fused constant and grant_once to identify the loop structures, I think we cannot realize it in FusePatternsPass.cpp

@tancheng
Copy link
Copy Markdown
Contributor

Can you explain a bit on: "Remove the grant_always operations in --transform-ctrl-to-data-pass"?

What would it look like if grant_always is removed? how is the constant passed in then?

@tancheng
Copy link
Copy Markdown
Contributor

Can you explain a bit on: "Remove the grant_always operations in --transform-ctrl-to-data-pass"?

What would it look like if grant_always is removed? how is the constant passed in then?

It looks like "replace" instead of "remove".

@ShangkunLi
Copy link
Copy Markdown
Collaborator Author

Can you explain a bit on: "Remove the grant_always operations in --transform-ctrl-to-data-pass"?
What would it look like if grant_always is removed? how is the constant passed in then?

It looks like "replace" instead of "remove".

We use the grant_once for all the live-out constant ops. And for constants used in other blocks, we use grant_once + grant_predicate to make it valid instead of using grant_always like before.

@tancheng
Copy link
Copy Markdown
Contributor

Where is --fuse-constant-and-grant-once?

@tancheng
Copy link
Copy Markdown
Contributor

Since I need the ir with fused constant and grant_once to identify the loop structures, I think we cannot realize it in FusePatternsPass.cpp

I don't get this. Why can't we simply fuse the constant -> grant_once pattern? Why do we need to "identify loop structures"?

@ShangkunLi
Copy link
Copy Markdown
Collaborator Author

Where is --fuse-constant-and-grant-once?

I haven't made a pr for it yet. And the transformed ir looks like:

module {
  func.func @_Z10simpleloopv() -> i32 attributes {accelerator = "neura", llvm.linkage = #llvm.linkage<external>} {
    %0 = "neura.grant_once"() <{constant_value = 1 : i64}> : () -> !neura.data<i64, i1>
    %1 = "neura.grant_once"() <{constant_value = 128 : i64}> : () -> !neura.data<i64, i1>
    %2 = "neura.grant_once"() <{constant_value = 0 : i32}> : () -> !neura.data<i32, i1>
    %3 = "neura.grant_once"() <{constant_value = 0 : i64}> : () -> !neura.data<i64, i1>
    %4 = neura.reserve : !neura.data<i64, i1>
    %5 = "neura.phi"(%4, %1) : (!neura.data<i64, i1>, !neura.data<i64, i1>) -> !neura.data<i64, i1>
    %6 = neura.reserve : !neura.data<i32, i1>
    %7 = "neura.phi"(%6, %2) : (!neura.data<i32, i1>, !neura.data<i32, i1>) -> !neura.data<i32, i1>
    %8 = neura.reserve : !neura.data<i64, i1>
    %9 = "neura.phi"(%8, %3) : (!neura.data<i64, i1>, !neura.data<i64, i1>) -> !neura.data<i64, i1>
    %10 = "neura.icmp"(%9, %5) <{cmpType = "slt"}> : (!neura.data<i64, i1>, !neura.data<i64, i1>) -> !neura.data<i1, i1>
    %11 = neura.grant_predicate %9, %10 : !neura.data<i64, i1>, !neura.data<i1, i1> -> !neura.data<i64, i1>
    %12 = neura.grant_predicate %7, %10 : !neura.data<i32, i1>, !neura.data<i1, i1> -> !neura.data<i32, i1>
    %13 = neura.grant_predicate %0, %10 : !neura.data<i64, i1>, !neura.data<i1, i1> -> !neura.data<i64, i1>
    %14 = neura.grant_predicate %1, %10 : !neura.data<i64, i1>, !neura.data<i1, i1> -> !neura.data<i64, i1>
    %15 = "neura.not"(%10) : (!neura.data<i1, i1>) -> !neura.data<i1, i1>
    %16 = neura.grant_predicate %7, %15 : !neura.data<i32, i1>, !neura.data<i1, i1> -> !neura.data<i32, i1>
    %17 = "neura.cast"(%11) <{cast_type = "i64_to_i32"}> : (!neura.data<i64, i1>) -> !neura.data<i32, i1>
    %18 = "neura.add"(%12, %17) : (!neura.data<i32, i1>, !neura.data<i32, i1>) -> !neura.data<i32, i1>
    %19 = "neura.add"(%11, %13) : (!neura.data<i64, i1>, !neura.data<i64, i1>) -> !neura.data<i64, i1>
    neura.ctrl_mov %19 -> %8 : !neura.data<i64, i1> !neura.data<i64, i1>
    neura.ctrl_mov %18 -> %6 : !neura.data<i32, i1> !neura.data<i32, i1>
    neura.ctrl_mov %14 -> %4 : !neura.data<i64, i1> !neura.data<i64, i1>
    "neura.return"(%16) : (!neura.data<i32, i1>) -> ()
  }
}

@ShangkunLi
Copy link
Copy Markdown
Collaborator Author

Since I need the ir with fused constant and grant_once to identify the loop structures, I think we cannot realize it in FusePatternsPass.cpp

I don't get this. Why can't we simply fuse the constant -> grant_once pattern? Why do we need to "identify loop structures"?

I see what you mean. I can modify this.

@ShangkunLi ShangkunLi closed this pull request by merging all changes into coredac:main in 7b2b374 Jul 31, 2025
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