Skip to content

AliasAnalysis handles slices.#1281

Merged
wujingyue merged 4 commits intomainfrom
wjy/slice
Nov 17, 2023
Merged

AliasAnalysis handles slices.#1281
wujingyue merged 4 commits intomainfrom
wjy/slice

Conversation

@wujingyue
Copy link
Collaborator

No description provided.

@wujingyue wujingyue marked this pull request as draft November 11, 2023 16:21
wujingyue added a commit that referenced this pull request Nov 12, 2023
This is separated from #1281 to keep the PR small.
wujingyue added a commit that referenced this pull request Nov 12, 2023
This is separated from #1281 to keep the PR small.
@wujingyue wujingyue changed the base branch from main to wjy/map November 13, 2023 04:34
wujingyue added a commit that referenced this pull request Nov 13, 2023
This is separated from #1281 to keep the PR small.
@wujingyue wujingyue marked this pull request as ready for review November 13, 2023 06:12
@wujingyue
Copy link
Collaborator Author

!build

@wujingyue
Copy link
Collaborator Author

!build

1 similar comment
@wujingyue
Copy link
Collaborator Author

!build

Base automatically changed from wjy/map to main November 13, 2023 18:38
wujingyue added a commit that referenced this pull request Nov 13, 2023
This is separated from #1281 to keep the PR small.
@naoyam
Copy link
Collaborator

naoyam commented Nov 13, 2023

Can this be split to two PRs, one for slices and another for reshapes?

@wujingyue
Copy link
Collaborator Author

Can this be split to two PRs, one for slices and another for reshapes?

Sure. Found more problems though: apparently, the pointwise scheduler changes the output contiguity, breaking ResizeTest.SliceAndReshape2. Looking...

@wujingyue
Copy link
Collaborator Author

Can this be split to two PRs, one for slices and another for reshapes?

Sure. Found more problems though: apparently, the pointwise scheduler changes the output contiguity, breaking ResizeTest.SliceAndReshape2. Looking...

This is the apparent root cause:

TensorView* new_output = IrBuilder::create<TensorView>(
doesn't copy allocation domain and contiguity.

@wujingyue
Copy link
Collaborator Author

Sure. Found more problems though: apparently, the pointwise scheduler changes the output contiguity, breaking ResizeTest.SliceAndReshape2. Looking...

This is the apparent root cause:

TensorView* new_output = IrBuilder::create<TensorView>(

doesn't copy allocation domain and contiguity.

Will be fixed by #1291

@wujingyue wujingyue changed the base branch from main to wjy/nonpack November 14, 2023 05:41
@wujingyue
Copy link
Collaborator Author

!build

@wujingyue wujingyue changed the title AliasAnalysis handles slices and non-packed reshapes. AliasAnalysis handles slices. Nov 14, 2023
}

// Scan through the allocation domain in minor-to-major order. If an
// IterDomain is sliced, the next non-broadcast IterDomain has to be marked
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it possible to encounter a trivial SliceOp here? Where both left and right pad are zero? We should treat such case as the identity on that axis.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agree with Jacob. i.e. if we later decide to merge a trivially sliced dimension, we should recognize that and merge it back I guess.

But this can only be done opportunistically (only handle static trivial slice), I guess?! Since padding value can be a runtime value and we can't know for sure that it'll be a trivial slice or not until runtime.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is it possible to encounter a trivial SliceOp here? Where both left and right pad are zero? We should treat such case as the identity on that axis.

return set(inp);
and
// This dim doesn't need slicing
have already done a good job filtering out trivial slices and trivial slice dimensions. So I'd rather keep the logic here simple.

out_layout.contiguity[i] = in_layout.contiguity[i];
}

std::vector<Expr*> dependencies = DependencyCheck::getAllExprsBetween(
Copy link
Collaborator

Choose a reason for hiding this comment

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

You can use StmtSort::getExprsBetween.

Copy link
Collaborator

@jacobhinkle jacobhinkle left a comment

Choose a reason for hiding this comment

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

This PR looks good to me. Note that a slice can also be achieved with a PadOp. In that case, we cannot assume the pads are negative, and if any are positive we must materialize. Otherwise we can alias just as you've done here.

@wujingyue
Copy link
Collaborator Author

This PR looks good to me. Note that a slice can also be achieved with a PadOp. In that case, we cannot assume the pads are negative, and if any are positive we must materialize. Otherwise we can alias just as you've done here.

Is the reverse also true? I.e. a SliceOp may take a negative offset, making it essentially a pad. That would break my analysis because a real pad has to be materialized.

@jjsjann123
Copy link
Collaborator

Should I review this one or wait until we split the PR into two per Naoya's suggestion?

@wujingyue
Copy link
Collaborator Author

Should I review this one or wait until we split the PR into two per Naoya's suggestion?

Already split

}

// Scan through the allocation domain in minor-to-major order. If an
// IterDomain is sliced, the next non-broadcast IterDomain has to be marked
Copy link
Collaborator

Choose a reason for hiding this comment

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

Agree with Jacob. i.e. if we later decide to merge a trivially sliced dimension, we should recognize that and merge it back I guess.

But this can only be done opportunistically (only handle static trivial slice), I guess?! Since padding value can be a runtime value and we can't know for sure that it'll be a trivial slice or not until runtime.

@jacobhinkle
Copy link
Collaborator

This PR looks good to me. Note that a slice can also be achieved with a PadOp. In that case, we cannot assume the pads are negative, and if any are positive we must materialize. Otherwise we can alias just as you've done here.

Is the reverse also true? I.e. a SliceOp may take a negative offset, making it essentially a pad. That would break my analysis because a real pad has to be materialized.

No. Slice will never pad. See #460.

@wujingyue
Copy link
Collaborator Author

This PR looks good to me. Note that a slice can also be achieved with a PadOp. In that case, we cannot assume the pads are negative, and if any are positive we must materialize. Otherwise we can alias just as you've done here.

Left a note on AliasFinder:handle(const SliceOp* slice) for future improvement.

Copy link
Collaborator

@jjsjann123 jjsjann123 left a comment

Choose a reason for hiding this comment

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

LGTM

Base automatically changed from wjy/nonpack to main November 17, 2023 19:22
wujingyue added a commit that referenced this pull request Nov 17, 2023
Partially taken from #1281 to keep that PR small.
With slices, the pointer address might not be the same.
PointerArithmetic is more accurate.
@wujingyue
Copy link
Collaborator Author

!build

@wujingyue wujingyue merged commit eef9db8 into main Nov 17, 2023
@wujingyue wujingyue deleted the wjy/slice branch November 17, 2023 20:36
wujingyue added a commit that referenced this pull request Nov 20, 2023
wujingyue added a commit that referenced this pull request Nov 20, 2023
wujingyue added a commit that referenced this pull request Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants