Pass call context for GEMM calls
> Please write a complete PR description - I have no context for this change

Sorry, missed that. Just added that info. 

Please let me know if you have any other questions. 

Thanks! @akuegel  I can see some failing CIs, but they are all internal. Can you please share what's failing?
Thanks! > @akuegel I can see some failing CIs, but they are all internal. Can you please share what's failing? Thanks!

The internal comment on the change:

"This triggers the full fallback mode of the TF2XLA bridge from any use of tf.MatMul in a program (rather than just running the XlaBuilder kernels for the MatMul Ops)."

But it seems this would need to be fixed internally by updating the TF dialect. > > @akuegel I can see some failing CIs, but they are all internal. Can you please share what's failing? Thanks!
> 
> The internal comment on the change:
> 
> "This triggers the full fallback mode of the TF2XLA bridge from any use of tf.MatMul in a program (rather than just running the XlaBuilder kernels for the MatMul Ops)."
> 
> But it seems this would need to be fixed internally by updating the TF dialect.

@akuegel ok, let me know if any changes are needed from me. Thanks! @rahulbatra85, Could you provide a draft for the docstring of the newly added grad_a, grad_b arguments in this CL? The linter is complaining about lack of Args entry in the docstring, and I'll just add the docstring in the internal clone of the PR before submitting it. It turns out the newly added attribute interacts with a bunch of other systems, such as quantization and TFL. I suppose the correct behavior is to just ignore the new attributes in those cases? > It turns out the newly added attribute interacts with a bunch of other systems, such as quantization and TFL. I suppose the correct behavior is to just ignore the new attributes in those cases?

@rainwoodman  
yes, the default is false. > @rahulbatra85, Could you provide a draft for the docstring of the newly added grad_a, grad_b arguments in this CL? The linter is complaining about lack of Args entry in the docstring, and I'll just add the docstring in the internal clone of the PR before submitting it.

grad_a, grad_b can be set to indicate if the op is done as part of backward pass ie gradient calculation. The idea is if it's set/unset then some optimizations can be done by the library, etc. Thanks! I'll go with the following then:
 ```
    grad_a: Set it to `True` to hint that Tensor `a` is for the backward pass.
    grad_b: Set it to `True` to hint that Tensor `b` is for the backward pass.
```

It may take a few additional days for it to go through the review process because of the larger footprint of the changes.

Be aware that the MLIR bridge (which is the default) doesn't yet default to use the XLABuilder kernels you have added. However the TableGen HLO lowering rules (preferred by the MLIR bridge) do not know how to pass down the new grad attributes -- I only fixed them to ignore the new attrs on the internal change. There is ongoing work to change the MLIR bridge to prefer XLABuilder kernels. (CC @changm ) > Thanks! I'll go with the following then:
> 
> ```
>    grad_a: Set it to `True` to hint that Tensor `a` is for the backward pass.
>    grad_b: Set it to `True` to hint that Tensor `b` is for the backward pass.
> ```
> 
> It may take a few additional days for it to go through the review process because of the larger footprint of the changes.
> 
> Be aware that the MLIR bridge (which is the default) doesn't yet default to use the XLABuilder kernels you have added. However the TableGen HLO lowering rules (preferred by the MLIR bridge) do not know how to pass down the new grad attributes -- I only fixed them to ignore the new attrs on the internal change. There is ongoing work to change the MLIR bridge to prefer XLABuilder kernels. (CC @changm )

@rainwoodman  ok, thanks! We will rollback the changes because some targets are failing due to the newly added attributes apparently become mandatory in certain cases. I will post an update for the rollforward before next week.
Adds gradient flags to ops to indicate whether forward or backward pass
Passes this call context to XLA for GEMM calls(See this XLA PR)
	 	https://github.com/openxla/xla/pull/6533
XLA passes this information to library call