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.

Sign up for GitHub

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

Lowering Aten op to composite op instead of small ops #8502

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Lowering Aten op to composite op instead of small ops #8502

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
49de8bc
Lowering Aten op to composite op instead of small ops.
Zantares Dec 18, 2024
c9ee78e
Fix format and remove version test info.
Zantares Dec 20, 2024
21501b7
Add Softmax and it's backward.
Zantares Jan 2, 2025
836aa97
Address composite op namespace.
Zantares Jan 10, 2025
cb891b4
Remove useless attr in Gelu/GeluBackward.
Zantares Jan 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 35 additions & 2 deletions torch_xla/csrc/ops/ops.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -692,7 +692,22 @@ torch::lazy::NodePtr Gelu(const torch::lazy::Value& input) {
auto lower_fn = [](const XlaNode& node,
LoweringContext* loctx) -> XlaOpVector {
xla::XlaOp xla_input = loctx->GetOutputOp(node.operand(0));
return node.ReturnOp(BuildGelu(xla_input), loctx);

// Building composite computation.
const std::string name = "composite.gelu";
Copy link
Collaborator

Choose a reason for hiding this comment

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

The purpose of namespacing is to be able to tell who the maintainer or origin of a given composite is. If something changes about GELU (new attr, etc) who is on the hook to maintain it (for composites this is usually intended to be a vendor who has a library nvidia.some_op, aws.some_op, litert.some_op etc). The name composite doesn't answer this question.

For this I'd recommend ptxla.gelu or aten.gelu as names.

Copy link
Collaborator

@GleasonK GleasonK Jan 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

As an aside, I'd be careful representing converting every (or even many) aten operations using composites. They have a maintenance overhead in terms of needing to consider forward/backward compatibilty (i.e. the above thing about "what if gelu changes, who fixes?"), for some ops like gelu/softmax its probably ok, they don't tend to change much and usually look somewhat uniform.

For other aten ops that have very specific HW support, I'd recommend an approach that decentralizes composite ownership/maintenance, i.e. FX graph rewrite-as-composite API or make composite builder work for these use cases. This is how Google AI Edge uses composites today, they own the library and the compatibility for the (very small) subset of ATen ops that they have HW support for.

Copy link
Collaborator

Choose a reason for hiding this comment

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

(cc @lsy323)

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for the suggestions, here are some of my thoughts:

  • The namespace ptxla sounds quite good, and I will address it.
  • Regarding the compatibility/ownership of these ops in this PR, I believe it still belongs totorch-xla. The reason is that I didn't re-implement these ops from scratch, I simply wrapped the original implementation (such as BuildGelu and LowerSoftmax) with a composite call. W/O this PR, those implementations would need to be fixed if there were any changes in the semantics. At the current stage, I don't have any plans to introduce new composite ops that don't have an original implementation in torch-xla
  • Since this PR is aimed at resolving training issues, I'm uncertain whether the composite builder will work or not. Judging from the discussions in the attached issues, it appears that it might not work for training purposes. Could you please share some examples or guidance on:

    FX graph rewrite-as-composite API or make composite builder work for these use cases.

Copy link
Author

Choose a reason for hiding this comment

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

Namespace is addressed.

const std::string attr = "{approximate = \"none\"}";
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a dummy str for testing purpose?

Copy link
Author

Choose a reason for hiding this comment

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

This is a real op attribution for GELU: https://pytorch.org/docs/stable/generated/torch.nn.GELU.html#torch.nn.GELU

The available value of approximate is none or tanh. The lowering process checks this attribution and decides the sub lower function here. As my changes are in the sub lower function, I manually set this attribution.

It's a common process for composite op which has attributions (defined as non-tensor inputs for composite op, e.g. dim for Softmax).

Copy link
Author

Choose a reason for hiding this comment

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

Maybe I can get the attribution from XlaOp instead of manually setting strings, I will try.

Copy link
Collaborator

@GleasonK GleasonK Jan 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

What information is important for optimizations on this op? One option could be to have the composites implied value be none, and not generate a composite if tanh is used, of if the value is needed, then this looks good as-is, not a great API for making these in XLA, since they're an MLIR-first feature currently. If an MLIR dep is allowed in this file, you could build an MLIR dict and then dump to string before calling the XLA builder method.

Copy link
Author

@Zantares Zantares Jan 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Actually, I believe that the approximate attribute here serves little purpose other than enhancing IR readability. Nevertheless, I've retained all the relevant information according to the public guidance stablehlo.composite. If no more further comments or feedback, I can remove this information.

Copy link
Author

Choose a reason for hiding this comment

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

approximate for Gelu and GeluBackward is removed.

xla::XlaBuilder builder(name);
xla::XlaOp arg = xla::Parameter(
&builder, 0, ShapeHelper::ShapeOfXlaOp(xla_input), "arg");
xla::XlaOp ret = BuildGelu(arg);
xla::XlaComputation computation = ConsumeValue(builder.Build(ret));

// Building call to computation.
std::vector<xla::XlaOp> inputs{xla_input};
xla::XlaOp output = xla::CompositeCall(loctx->builder(), computation, inputs, name,
attr, /*version=*/1);
Copy link
Collaborator

Choose a reason for hiding this comment

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

ditto for version

Copy link
Author

Choose a reason for hiding this comment

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

Yes this is for testing, I learned this setting from this XLA UT. I can remove it if it makes no scense.

Copy link
Author

Choose a reason for hiding this comment

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

version is removed.


return node.ReturnOp(output, loctx);
};
return GenericOp(torch::lazy::OpKind(at::aten::gelu), {input},
GetXlaShape(input), std::move(lower_fn));
Expand All @@ -704,7 +719,25 @@ torch::lazy::NodePtr GeluBackward(const torch::lazy::Value& grad_output,
LoweringContext* loctx) -> XlaOpVector {
xla::XlaOp xla_grad_output = loctx->GetOutputOp(node.operand(0));
xla::XlaOp xla_input = loctx->GetOutputOp(node.operand(1));
return node.ReturnOp(BuildGeluBackward(xla_grad_output, xla_input), loctx);

// Building composite computation.
const std::string name = "composite.gelu_backward";
const std::string attr = "{approximate = \"none\"}";
xla::XlaBuilder builder(name);
xla::XlaOp arg_grad_output =
xla::Parameter(&builder, 0, ShapeHelper::ShapeOfXlaOp(xla_grad_output),
"arg_grad_output");
xla::XlaOp arg_input = xla::Parameter(
&builder, 1, ShapeHelper::ShapeOfXlaOp(xla_input), "arg_input");
xla::XlaOp ret = BuildGeluBackward(arg_grad_output, arg_input);
xla::XlaComputation computation = ConsumeValue(builder.Build(ret));

// Building call to computation.
std::vector<xla::XlaOp> inputs{xla_grad_output, xla_input};
xla::XlaOp output = xla::CompositeCall(loctx->builder(), computation, inputs, name,
attr, /*version=*/1);

return node.ReturnOp(output, loctx);
};
return GenericOp(torch::lazy::OpKind(at::aten::gelu_backward),
{grad_output, input}, GetXlaShape(input),
Expand Down
Loading