Skip to content
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

[microTVM] add the option to open a saved micro project for debugging #12495

Merged
merged 2 commits into from
Sep 27, 2022

Conversation

mkatanbaf
Copy link
Contributor

@mkatanbaf mkatanbaf commented Aug 18, 2022

This PR adds the option to save a generated micro project at a custom path, and to open a saved project and start communicating with it (instead of generating a new one) for debugging.

cc @alanmacd @areusch @gromero @guberti @mehrdadh

@mkatanbaf mkatanbaf changed the title [microTVM] add the option to open a saved project for debugging [microTVM] add the option to open a saved micro project for debugging Aug 18, 2022
@mkatanbaf mkatanbaf force-pushed the debug_autotune_projects branch from f0da470 to 25c8e77 Compare August 30, 2022 18:09
@mkatanbaf mkatanbaf marked this pull request as ready for review August 31, 2022 16:57
@github-actions github-actions bot requested review from areusch and mehrdadh August 31, 2022 17:07
Copy link
Contributor

@areusch areusch left a comment

Choose a reason for hiding this comment

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

@@ -259,6 +259,8 @@ def compile_and_create_micro_session(
mod_src_bytes: bytes,
template_project_dir: str,
project_options: dict = None,
build_dir: str = None,
debug: bool = False,
Copy link
Contributor

Choose a reason for hiding this comment

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

could we use a more descriptive parameter name? e.g. reuse_project or generate_project: bool = True? alternatively, could derive this from build_dir (e.g. if it already exists, don't regenerate); but that could be troublesome if we want to assert a workflow actually generates a project too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

how about skip_project_generation: bool = False? yes, we can drive it from build_dir but I think that might cause some confusion and it's better to explicitly express it when we would like to skip project generation.

Copy link
Member

Choose a reason for hiding this comment

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

I like reuse_project or use_existing. I also agree that deriving this property from build_dir would cause confusion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used use_existing. Thanks @guberti for the suggestion.

logging.error("Project Generate Error: %s", str(exception))
raise exception

generated_project.build()
Copy link
Contributor

Choose a reason for hiding this comment

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

should we still rebuild if we're going to flash? i mean, maybe not..just wondering some rationale here.

Copy link
Contributor Author

@mkatanbaf mkatanbaf Aug 31, 2022

Choose a reason for hiding this comment

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

based on what I've seen the flash step rebuilds the project if needed. The build step creates the build dir for the first time and I believe it generates an error if the build dir already exists. I'll double check.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I checked and the west flash command rebuilds the project if needed.

Copy link
Member

@guberti guberti Sep 2, 2022

Choose a reason for hiding this comment

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

I do not believe the Arduino implementation does this - how do we want to handle that? IMO the cleanest/easiest solution is to always rebuild before flashing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I changed it to clear the existing build dir, and rebuild before flashing.

**(project_options or {}),
},
)
project.build()
Copy link
Contributor

Choose a reason for hiding this comment

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

same question here

Copy link
Member

@guberti guberti left a comment

Choose a reason for hiding this comment

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

LGTM, just a few nits. I don't have a strong opinion on whether we should rebuild existing projects before flashing - either seems reasonable to me (though I think we would have to remove the existing build dir if we rebuild)

After thinking about it more, I think one of the most common use cases for this feature will be letting folks make manual changes to the generated C++ code, and then evaluating how performance changes. Since calls to this utility will usually be accompanied by code changes, I think rebuilding explicitly by calling project.build() makes sense.

@@ -259,6 +259,8 @@ def compile_and_create_micro_session(
mod_src_bytes: bytes,
template_project_dir: str,
project_options: dict = None,
build_dir: str = None,
debug: bool = False,
Copy link
Member

Choose a reason for hiding this comment

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

I like reuse_project or use_existing. I also agree that deriving this property from build_dir would cause confusion.

Comment on lines 142 to 147
{
f"{platform}_board": board,
"project_type": "host_driven",
# {} shouldn't be the default value for project options ({}
# is mutable), so we use this workaround
**(project_options or {}),
Copy link
Member

Choose a reason for hiding this comment

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

Can we store these in a variable (e.g. project_options) so this code isn't duplicated between the if and else statements?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

self,
template_project_dir: Union[pathlib.Path, str],
project_options: dict = None,
build_dir: str = None,
Copy link
Member

Choose a reason for hiding this comment

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

Can we give build_dir a path-like object type instead of just str? i.e. Union[os.PathLike, str]?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@github-actions github-actions bot requested a review from gromero September 2, 2022 07:42
@mkatanbaf mkatanbaf force-pushed the debug_autotune_projects branch from 6c6af0f to 32a652a Compare September 2, 2022 08:28
@areusch
Copy link
Contributor

areusch commented Sep 7, 2022

@guberti can you have another look?

Copy link
Member

@guberti guberti left a comment

Choose a reason for hiding this comment

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

Two small comments, but this still looks good.

Comment on lines 134 to 136
template_project_dir: Union[pathlib.Path, str],
project_options: dict = None,
project_dir: Union[pathlib.Path, str] = None,
Copy link
Member

Choose a reason for hiding this comment

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

Nit: the Python docs suggest using os.PathLike for typechecking, which is the abstract base class for pathlib.Path.

Suggested change
template_project_dir: Union[pathlib.Path, str],
project_options: dict = None,
project_dir: Union[pathlib.Path, str] = None,
template_project_dir: Union[os.PathLike, str],
project_options: dict = None,
project_dir: Union[os.PathLike, str] = None,


if use_existing:
project_dir = pathlib.Path(project_dir)
assert pathlib.Path(project_dir).is_dir(), f"{project_dir} does not exist."
Copy link
Member

Choose a reason for hiding this comment

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

No need to call pathlib.Path twice.

Suggested change
assert pathlib.Path(project_dir).is_dir(), f"{project_dir} does not exist."
assert project_dir.is_dir(), f"{project_dir} does not exist."

@mkatanbaf
Copy link
Contributor Author

@tvm-bot rerun

1 similar comment
@mkatanbaf
Copy link
Contributor Author

@tvm-bot rerun

Copy link
Member

@guberti guberti left a comment

Choose a reason for hiding this comment

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

LGTM - thanks for the fix!

@mkatanbaf
Copy link
Contributor Author

@tvm-bot rerun

2 similar comments
@mkatanbaf
Copy link
Contributor Author

@tvm-bot rerun

@mkatanbaf
Copy link
Contributor Author

@tvm-bot rerun

@mkatanbaf mkatanbaf force-pushed the debug_autotune_projects branch from 1b75133 to 9ccdd30 Compare September 15, 2022 17:08
@mkatanbaf
Copy link
Contributor Author

@areusch could you take another look please?

@mkatanbaf
Copy link
Contributor Author

@tvm-bot rerun

@areusch areusch merged commit 82e6fc4 into apache:main Sep 27, 2022
xinetzone pushed a commit to daobook/tvm that referenced this pull request Nov 25, 2022
…apache#12495)

* add the option to open a saved project for debugging.

* addressing comments

Co-authored-by: Mohamad <mkatanbaf@users.noreply.github.com>
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.

3 participants