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.

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

Issue #3925 : Remove hvx_64 #5365

Merged
merged 24 commits into from Oct 21, 2020
Merged

Issue #3925 : Remove hvx_64 #5365

merged 24 commits into from Oct 21, 2020

Conversation

pranavb-ca
Copy link
Contributor

  • Removes hvx_64
  • Adds a target feature hvx which defaults to Target::HVX_128

I think we should keep hvx_128 around for a little bit and before ripping it out and simply going by hvx

fixes #3925

Copy link
Contributor

@dsharletg dsharletg left a comment

Choose a reason for hiding this comment

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

Two things that affect a ton of instances:

  • Should we just make Target::HVX_128 == Target::HVX, so we can simplify all instances that check these to just check Target::HVX?
  • There are a lot of instances of vector_size = get_target()... ? 128 : 64 that should just be vector_size = 128 now?

if (get_target().features_any_of({Target::HVX_64, Target::HVX_128})) {
const int vector_size = get_target().has_feature(Target::HVX_128) ? 128 : 64;
if (get_target().features_any_of({Target::HVX, Target::HVX_128})) {
const int vector_size = get_target().features_any_of({Target::HVX, Target::HVX_128}) ? 128 : 64;
Copy link
Contributor

Choose a reason for hiding this comment

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

constant 128

@pranavb-ca
Copy link
Contributor Author

Two things that affect a ton of instances:

  • Should we just make Target::HVX_128 == Target::HVX, so we can simplify all instances that check these to just check Target::HVX?
  • There are a lot of instances of vector_size = get_target()... ? 128 : 64 that should just be vector_size = 128 now?

dang it - i thought I caught all of those instances. I grepped for HVX_64 and that's why I think I missed out some of those. Will do.

@pranavb-ca
Copy link
Contributor Author

Two things that affect a ton of instances:

  • Should we just make Target::HVX_128 == Target::HVX, so we can simplify all instances that check these to just check Target::HVX?

Actually that is what I have done, but in a sed frenzy I went ahead and changed has_feature to features_any_of

src/Target.h Outdated Show resolved Hide resolved
if (get_target().has_feature(Target::HVX_128)) {
strip_size = processed.dim(1).extent() / 2;
} else if (get_target().has_feature(Target::HVX_64)) {
if (get_target().has_feature(Target::HVX)) {
strip_size = processed.dim(1).extent() / 4;
Copy link
Contributor

Choose a reason for hiding this comment

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

Keep the HVX_128 branch, not the HVX_64 branch.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I jumped the gun a little bit here. Newer cores have 4 contexts, but presently the lowest we support still has 2 contexts. I'll switch it back to / 2 ;

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I see. Actually, I think having more strips than cores is fine, so maybe keeping this 4 is best.

{Halide::Target::HVX_128, Halide::Target::HVX_64}))
<< "Cannot set both HVX_64 and HVX_128 at the same time.\n";
user_assert(target.has_feature(Target::HVX))
<< "Creating a Codegen target for Hexagon without the hvx_128 or the hvx target feature.\n";
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove hvx_128 from this message?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I left it in the message to indicate to users that hvx_128 is still ok to use as a feature.

src/Target.cpp Outdated
@@ -871,13 +870,10 @@ int Target::natural_vector_size(const Halide::Type &t) const {

if (arch == Target::Hexagon) {
if (is_integer) {
// HVX is either 64 or 128 *byte* vector size.
if (has_feature(Halide::Target::HVX_128)) {
if (features_any_of({Halide::Target::HVX, Halide::Target::HVX_128})) {
Copy link
Contributor

Choose a reason for hiding this comment

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

features(...)

src/Target.cpp Outdated
@@ -966,7 +962,7 @@ bool Target::get_runtime_compatible_target(const Target &other, Target &result)
}

if ((features & matching_mask) != (other.features & matching_mask)) {
Internal::debug(1) << "runtime targets must agree on SoftFloatABI, Debug, TSAN, ASAN, MSAN, HVX_64, HVX_128, HexagonDma, and HVX_shared_object\n"
Internal::debug(1) << "runtime targets must agree on SoftFloatABI, Debug, TSAN, ASAN, MSAN, HVX_128, HexagonDma, and HVX_shared_object\n"
Copy link
Contributor

Choose a reason for hiding this comment

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

HVX_128 -> HVX

src/Target.cpp Outdated Show resolved Hide resolved
test/correctness/simd_op_check_hvx.cpp Outdated Show resolved Hide resolved
test/correctness/simd_op_check_hvx.cpp Outdated Show resolved Hide resolved
Copy link
Contributor

@dsharletg dsharletg left a comment

Choose a reason for hiding this comment

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

I don't know why I can't reply to any of the existing threads on the "conversation" tab... but regarding:

I left it in the message to indicate to users that hvx_128 is still ok to use as a feature.

If it's going to be deprecated, wouldn't it make sense to just encourage use of hvx?

src/HexagonOffload.cpp Show resolved Hide resolved
apps/camera_pipe/camera_pipe_generator.cpp Outdated Show resolved Hide resolved
@alexreinking alexreinking added this to the v12.0.0 milestone Oct 16, 2020
@pranavb-ca
Copy link
Contributor Author

@dsharletg - Addressed comments from the last review

Copy link
Contributor

@dsharletg dsharletg left a comment

Choose a reason for hiding this comment

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

Thanks for the fixes!

pranavb-ca added a commit to pranavb-ca/build_bot that referenced this pull request Oct 20, 2020
@steven-johnson
Copy link
Contributor

LGTM -- pushed a partial change to the buildbot to avoid the hvx64 build errors, then synced this to master. Let's let it go green before landing.

@dsharletg
Copy link
Contributor

This is failing on some of the buildbots:

make: *** No rule to make target 'bin/build/initmod.hvx_64_ll.o', needed by 'bin/libHalide.so'.  Stop.
make: *** Waiting for unfinished jobs....

Looking at the PR, I don't see any changes to either Makefile or CMakeLists.txt, both should probably change.

@pranavb-ca
Copy link
Contributor Author

halide/build_bot#108

@dsharletg
Copy link
Contributor

I think that's a different thing. Yes, the hvx_64 tests will fail to run. But here, libHalide.so is failing to link at all. I think because these two lines need to be removed:

https://github.com/halide/Halide/blob/master/Makefile#L829
https://github.com/halide/Halide/blob/master/src/runtime/CMakeLists.txt#L105

@pranavb-ca
Copy link
Contributor Author

I think that's a different thing. Yes, the hvx_64 tests will fail to run. But here, libHalide.so is failing to link at all. I think because these two lines need to be removed:

https://github.com/halide/Halide/blob/master/Makefile#L829
https://github.com/halide/Halide/blob/master/src/runtime/CMakeLists.txt#L105

Yes, you are right. I was simply reminded of my PR from yesterday because of your comment and so pasted that here. I had taken care of CMakeLists.txt in a previous commit. Just pushed one more change to remove it from Halide/Makefile

@alexreinking
Copy link
Member

I think we should keep hvx_128 around for a little bit and before ripping it out and simply going by hvx

If we hold off merging this until v11.0.0 is released, then we don't need to wait at all.

@dsharletg
Copy link
Contributor

This has passed all the build bots, @alexreinking is there really a reason to wait to merge this? It isn't a breaking change (unless you are using hvx_64 of course). hvx_128 remains as a useful flag, it's just deprecated (and it is only silently deprecated at this point). I think the steps here are:

  1. Remove hvx_64 (this PR)
  2. Deprecate hvx_128 by warning people to use hvx instead.
  3. Remove hvx_128 and only support hvx.

I think we should do 1 now that this PR is ready to merge, and avoid generating inevitable merge conflicts for this PR to manage later.

2 and 3 aren't planned for any particular time yet. 2 and 3 should probably be in separate releases of course.

@alexreinking
Copy link
Member

It's totally fine to put this through a deprecation plan. I thought this PR might not be ready for the v11.0 release, but it looks like I misread the room :)

@dsharletg
Copy link
Contributor

OK, I think I'll let @pranavb-ca decide when to merge it. I was also mistaken, some of the build bots are still running.

@steven-johnson
Copy link
Contributor

I agree with @dsharlet -- happy to go ahead and land before branching the 11 release. Buildbots are clean, there's just one merge conflict to resolve.

@steven-johnson
Copy link
Contributor

UPDATE: the merge conflict was due to my clang-tidy changes, so I went ahead and pushed the fix. Should be good to merge anytime.

@alexreinking alexreinking modified the milestones: v12.0.0, v11.0.0 Oct 21, 2020
@steven-johnson
Copy link
Contributor

Green, OK to land

@pranavb-ca pranavb-ca merged commit 31f1937 into master Oct 21, 2020
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.

Should HVX_64 support be deprecated?
4 participants