-
Notifications
You must be signed in to change notification settings - Fork 16
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
[Optimizer] Refactor legal gird analysis #1363
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clang-Tidy
found issue(s) with the introduced code (1/1)
@@ -0,0 +1,20 @@ | |||
// RUN: ttmlir-opt --ttir-to-ttnn-backend-pipeline="enable-optimizer=true override-output-layout=add_1=:::row_major:" %s | FileCheck %s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like how this looks, should be in format similar to named parameters in case all options are not specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. Are you suggesting that we have multiple options on syntax for overrides or that we switch to always named?
Named might get a bit verbose and we might run out of meaningful separator characters.
E.g:
override-output-layout=add_1=buffer_type=l1:tensor_memory_layout=block_sharded:memory_layout=row_major:data_type=f32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look how named params work, you can omit them if you specify all params in correct order, if overriding only partially you need to specify param names. I agree verbosity is getting out of hand, maybe we can shorten names a bit. Lets think about it more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can shorten param names:
override-output-layout=add_1=bt=l1:tml=block_sharded:ml=row_major:dt=f32 and avoid them if all are specified in order:
override-output-layout=add_1=l1:block_sharded:row_major:f32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed offline, change to support any number of layout params with deducing type of param by value.
93193c8
to
56188a9
Compare
|
||
// Create element type for the new layout. | ||
Type elementType = layout.getScalarElementType(); | ||
if (override.dataType.has_value()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default is row major?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, TILE / ROW_MAJOR is always overriden in this path and is controled with the next if: if (override.memoryLayout == Layout::Tile)
.
This checks dataType which is allowed to not be present and is copied over from the existing tensor if not overriden.
// Apply partial layout overrides. | ||
if (override.has_value()) { | ||
analysisResult.erase( | ||
std::remove_if(analysisResult.begin(), analysisResult.end(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not like this approach. Can we at the beginning load all overrides and not even add layout not compatible with overrides instead of adding all and then removing them. At the very minimal create a util function instead of this lambda remove_if approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started with that approach and implemented a solution where i first create a search space for each layout param, then apply overrides and then try to itterate over the cros product and generate legal solutions. This was very hard to read because it ended up having a lot of nested if to check for non compatible cases across parameters. So i decided to go back to this which is cleaner an less error prone. I understand we are trading of performance for readability here, but it seems logical atm?
Will extract into a seperate funciton.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dialect-side changes lgtm!
@nsmithtt @tapspatel @vprajapati-tt Can someone take a look at the PR, your approval is required. I think that the only change not reviewed is this file https://github.com/tenstorrent/tt-mlir/pull/1363/files#diff-694f570cfe79f8e3130bde9637283269c8c33048a68ce3b3fd15be810b11d961 Will update codeowners for this in the future. |
llvm::cl::opt<std::string> OverrideOutputLayoutOption{ | ||
"override-output-layout"}; | ||
OutputLayoutOverrideParser parser{OverrideOutputLayoutOption}; | ||
llvm::StringMap<OutputLayoutOverrideParams> parsedOverride; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@odjuricicTT, I think this might have broken macOS build: https://github.com/tenstorrent/tt-mlir/actions/runs/12269439074/job/34232997171
OptimizerTests: CommandLine Error: Option 'override-output-layout' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
Perhaps this fixture gets instantiated many times?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems so. Thanks for pointing it out. Will take a look asap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried a potential fix here: #1589
But I'm unable to repro locally, it feels like a build config issue actually, I think the usage of parser.parse
is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"sharded:row_major:f16"; | ||
|
||
bool result = parser.parse(OverrideOutputLayoutOption, | ||
"override-output-layout", arg, parsedOverride); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@odjuricicTT, see comment above, maybe this one is the culprit:
[ RUN ] OutputLayoutOverrideTest.ParseMultipleOps
OptimizerTests: CommandLine Error: Option 'override-output-layout' registered more than once!
* Rename to LegalLayoutAnalysis * Add generation of both TILE and ROW_MAJOR layouts * Keep ROW_MAJOR disabled by default and add flag to enable when needed * Explicitly generate all layout related parameters (except for data format). * Adjust overrides to support partial output layout instead of every param * Clean up optimizer mlir tests
PR contains the following:
Left to do: