Skip to content

[P1] Investigate/refactor the cost/award estimation for mapping #59

@tancheng

Description

@tancheng

#58 enables the simple cost/award estimation for MRRG mapping.

However, it is now super rough and when I try to include the utilization (e.g., lower utilized tile should be prioritized for placement of an operation), the compiled II unfortunately becomes worse.

For now, the simple for loop's RecMII = 4, ResMII = 1, but CompiledII = 6:

// MAPPING: func.func @loop_test() -> f32 attributes {CompiledII = 6 : i32, RecMII = 4 : i32, ResMII = 1 : i32, accelerator = "neura"} {

Our goal is to decrease CompiledII from 6 to 4. Note that the pattern matching is orthogonal, which can make RecMII = 1 hopefully.

TODO:

  • Figure out why more consideration leads to worse compiled II.
  • Include the utilization of HW resources into the heuristic mapping.
  • Enable backtrack for operation placement, i.e., if mapping is not valid when an operation is being placed or when a move operation is being routed, we need to backtrack to the previous/producer operation's placement.

Metadata

Metadata

Labels

bugSomething isn't workingnew featureNew feature or request

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions