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
Conversation
There was a problem hiding this 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 checkTarget::HVX
? - There are a lot of instances of
vector_size = get_target()... ? 128 : 64
that should just bevector_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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
constant 128
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. |
Actually that is what I have done, but in a sed frenzy I went ahead and changed |
…64 now that HVX_128 is the only mode for HVX
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ;
There was a problem hiding this comment.
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.
src/CodeGen_Hexagon.cpp
Outdated
{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"; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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})) { |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HVX_128 -> HVX
There was a problem hiding this 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
?
@dsharletg - Addressed comments from the last review |
There was a problem hiding this 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!
Merge this after halide/Halide#5365 is merged.
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. |
This is failing on some of the buildbots:
Looking at the PR, I don't see any changes to either Makefile or CMakeLists.txt, both should probably change. |
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 |
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 |
If we hold off merging this until v11.0.0 is released, then we don't need to wait at all. |
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:
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. |
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 :) |
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. |
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. |
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. |
Green, OK to land |
hvx
which defaults toTarget::HVX_128
I think we should keep
hvx_128
around for a little bit and before ripping it out and simply going byhvx
fixes #3925