[ghstack-poisoned]

Summary
- Previously this was required by `tracing_mode=symbolic` for `dynamic` tracing.
  That argument will be dropped by #99555.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Functionalization currently cannot work properly on aten level graph.
  So it must happen before lowering & decompositions.

[ghstack-poisoned]

Summary
- Previously this was required by `tracing_mode=symbolic` for `dynamic` tracing.
  That argument will be dropped by #99555.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Functionalization currently cannot work properly on aten level graph.
  So it must happen before lowering & decompositions.
- Introduce `ReplaceInplacePostFunctionalization` pass to replace inplace variant ops with outplace version.
  These ops are created by aten graph lowering and decomposition post functionalization. They
  won't be doing any real mutation as it is expected to have been handled by functionalization.

Workaround to unblock #99662.

[ghstack-poisoned]

Summary
- Previously this was required by `tracing_mode=symbolic` for `dynamic` tracing.
  That argument will be dropped by #99555.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Functionalization currently cannot work properly on aten level graph.
  So it must happen before lowering & decompositions.
- Introduce `ReplaceInplacePostFunctionalization` pass to replace inplace variant ops with outplace version.
  These ops are created by aten graph lowering and decomposition post functionalization. They
  won't be doing any real mutation as it is expected to have been handled by functionalization.

Workaround to unblock #99662.

[ghstack-poisoned]

…] Drop 'aten_graph' arg for 'DynamoExporter'"


Summary
- Previously this was required by `tracing_mode=symbolic` for `dynamic` tracing.
  That argument will be dropped by #99555.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Functionalization currently cannot work properly on aten level graph.
  So it must happen before lowering & decompositions.
- Introduce `ReplaceInplacePostFunctionalization` pass to replace inplace variant ops with outplace version.
  These ops are created by aten graph lowering and decomposition post functionalization. They
  won't be doing any real mutation as it is expected to have been handled by functionalization.

Workaround to unblock #99662.

[ghstack-poisoned]

…h' arg for 'DynamoExporter'"


Summary
- Previously this was required by `tracing_mode=symbolic` for `dynamic` tracing.
  That argument will be dropped by #99555.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Functionalization currently cannot work properly on aten level graph.
  So it must happen before lowering & decompositions.
- Introduce `ReplaceInplacePostFunctionalization` pass to replace inplace variant ops with outplace version.
  These ops are created by aten graph lowering and decomposition post functionalization. They
  won't be doing any real mutation as it is expected to have been handled by functionalization.

Workaround to unblock #99662.

[ghstack-poisoned]

…orkaround in 'Functionalize' pass"


Summary
- Previously this was required by and entangled with `tracing_mode=symbolic` for `dynamic` tracing.
  That is resolved by #99555 and its follow ups.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Updated `Functionalization` to workaround #99774 (comment)

Todo
- Training vs eval in dynamo_export
  So we are effectively exporting all models in traning mode by
  default. But for the sake of this export we are only interested in eval mode.
  The question is, should we call `model.eval()` in `dynamo_export`?
  Tests with model containing batch norm fails 'functionalization' in training mode.
  We are explicitly calling `model.eval()` for these model for now.
- Merge decomp and functionalize pass. Both calls into `make_fx`.
  Merging potentially increases performance. However it is unclear
  if it will result in different behavior.

Workaround to unblock #99662.

[ghstack-poisoned]

…orkaround in 'Functionalize' pass"


Summary
- Previously this was required by and entangled with `tracing_mode=symbolic` for `dynamic` tracing.
  That is resolved by #99555 and its follow ups.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Updated `Functionalization` to workaround #99774 (comment)

Todo
- Training vs eval in dynamo_export
  So we are effectively exporting all models in traning mode by
  default. But for the sake of this export we are only interested in eval mode.
  The question is, should we call `model.eval()` in `dynamo_export`?
  Tests with model containing batch norm fails 'functionalization' in training mode.
  We are explicitly calling `model.eval()` for these model for now.
- Merge decomp and functionalize pass. Both calls into `make_fx`.
  Merging potentially increases performance. However it is unclear
  if it will result in different behavior.

Workaround to unblock #99662.

[ghstack-poisoned]

…orkaround in 'Functionalize' pass"


Summary
- Previously this was required by and entangled with `tracing_mode=symbolic` for `dynamic` tracing.
  That is resolved by #99555 and its follow ups.
- Later decomposition pass will do graph lowering, so this step is duplicated.
- Updated `Functionalization` to workaround #99774 (comment)

Todo
- Training vs eval in dynamo_export
  So we are effectively exporting all models in traning mode by
  default. But for the sake of this export we are only interested in eval mode.
  The question is, should we call `model.eval()` in `dynamo_export`?
  Tests with model containing batch norm fails 'functionalization' in training mode.
  We are explicitly calling `model.eval()` for these model for now.
- Merge decomp and functionalize pass. Both calls into `make_fx`.
  Merging potentially increases performance. However it is unclear
  if it will result in different behavior.

Workaround to unblock #99662.

[ghstack-poisoned]