[inductor] Added smooth_l1_loss refs

[vfdev-5]

Added smooth_l1_loss to refs + tests

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @lezcano

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/102077

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit c6ade94:
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[lezcano]

Just a minor point, otherwise this LGTM. Approved contingent on that and the tests passing

[ngimel]

why do you need this conditional?

[vfdev-5]

Python nn functional API does the same:

pytorch/torch/nn/functional.py

Lines 3242 to 3245 in 76af221

	if beta == 0.0:
	return torch._C._nn.l1_loss(expanded_input, expanded_target, _Reduction.get_enum(reduction))
	else:
	return torch._C._nn.smooth_l1_loss(expanded_input, expanded_target, _Reduction.get_enum(reduction), beta)

[lezcano]

I don't think we have enough logic as to optimise this example out in practice, as it would mean that we need to prove that (input-target).abs() is not negative. The conditional is alright for now.

[ngimel]

wdym? .abs() is non-negative. Functional API does this due to some numeric discrepancies in backward, this doesn't apply here.

[lezcano]

Ok, my point simply comes from a perf perspective, wheere we would be computing both branches of the where and just using one, but probably LLVM should be able to catch the < 0 after .abs() and optimise it out.

That being said, I still think that keeping this closer to core is better, as we could think of eventually registering this operation and simply differentiating through it to get its backward. This beta==0 specialisation would make sure that this works in that case, as it does in master.

[vfdev-5]

@pytorchbot merge

[pytorchmergebot]

Merge failed

Reason: This PR needs a release notes: label
If your changes are user facing and intended to be a part of release notes, please use a label starting with release notes:.

If not, please add the topic: not user facing label.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "topic: not user facing"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

Details for Dev Infra team

Raised by workflow job

[vfdev-5]

@pytorchbot merge

[pytorchmergebot]

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here