Skip to content

Conversation

@wschin
Copy link
Collaborator

@wschin wschin commented Mar 30, 2022

Fixes #74519

@facebook-github-bot
Copy link
Contributor

facebook-github-bot commented Mar 30, 2022

🔗 Helpful links

💊 CI failures summary and remediations

As of commit b155c3c (more details on the Dr. CI page):


💚 💚 Looks good so far! There are no failures yet. 💚 💚


This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

Copy link
Contributor

Choose a reason for hiding this comment

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

aha. so basically the code we use to generate the counter names is behaving differently on windows?

Any idea if we could fix that instead? (to make it behave the same as linux) rather than patching the test to expect different behavior on windows?

https://github.com/pytorch/pytorch/blob/master/torch/csrc/lazy/ts_backend/ts_eager_fallback.cpp#L109

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's probably related to the name of struct torch::lazy::LazyTensorNativeFunctions. For example, this

at::Tensor LazyNativeFunctions::alias(const at::Tensor& self) {
  TORCH_LAZY_FN_COUNTER("lazy::");
  return self;
}

is expanded to

#define TORCH_LAZY_FN_COUNTER(ns) \
  TORCH_LAZY_COUNTER(c10::str(ns, __FUNCTION__), 1)

I assume __FUNCTION__ is mapped to fully-qualified name.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea, it seems like FUNCTION expands to alias on linux but torch::lazy::LazyTensorNativeFunctions:alias on windows. We actually don't want the full name for our purposes (having the counter named torch::lazy::LazyTensorNativeFunctions:alias is not ideal).

I wonder if there is some msvc trick or another preprocessor directive we could use so that we can get just the local function name without namespace on both linux/windows?

Copy link
Collaborator Author

@wschin wschin Mar 31, 2022

Choose a reason for hiding this comment

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

Maybe this can help.

#define TORCH_LAZY_FN_COUNTER(ns) \
  TORCH_LAZY_COUNTER(c10::str(ns, __func__), 1)

Basically, __func__ is defined in C/C++ standard so we should use __func__ instead of non-standardized __FUNCTION__ (which has different implementations in different compilers).

@wconstab
Copy link
Contributor

Cool, the __func__ solution looks good to me, I need to confirm it doesn't change behavior for linux, our CI seems to be messed up today, hopefully you can get a clean CI run tomorrow and i'll merge it.

@facebook-github-bot
Copy link
Contributor

@wconstab has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@wschin wschin force-pushed the fix-ltc-win-ltc-test branch 2 times, most recently from 60104f0 to 93011f6 Compare April 1, 2022 06:03
@wschin wschin force-pushed the fix-ltc-win-ltc-test branch from 93011f6 to b155c3c Compare April 1, 2022 06:08
@wschin wschin closed this Apr 1, 2022
@wschin wschin reopened this Apr 1, 2022
@facebook-github-bot
Copy link
Contributor

@wconstab has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

facebook-github-bot pushed a commit that referenced this pull request Apr 1, 2022
Summary:
Fixes #74519

Pull Request resolved: #74960

Reviewed By: gmagogsfm, cpuhrsch

Differential Revision: D35297620

Pulled By: wconstab

fbshipit-source-id: ef0ee27d29cd5a08afbaabeac9b254801555f70a
@github-actions
Copy link
Contributor

github-actions bot commented Apr 1, 2022

Hey @wschin.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Lazy TS Test Failures

4 participants