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

Disable column_view data accessors for unsupported types #7725

Merged
merged 43 commits into from
Mar 30, 2021

Conversation

jrhemstad
Copy link
Contributor

@jrhemstad jrhemstad commented Mar 25, 2021

Fixes #7712

column_view provides data accessors like column_view::data<T> and column_view::begin<T>. These accessors are only valid for fixed-width primitive types that can be constructed by simply casting the underlying void* to T*.

However, the accessors never actually enforced this rule, e.g., column_view::data<struct_view> should fail to compile.

This PR disables these accessors for invalid types.

This uncovered a number of places that were erroneously instantiating column_view accessors, which would lead to silent failures (e.g., scatter was failing silently for struct columns).

I added a few new things to aid me in this effort:

  • CUDF_ENABLE_IF macro to make it easier to SFINAE.
  • is_rep_layout_compatbile<T>() to identify types that are layout compatible with their rep (e.g., duration_ns is layout compatible with its int64_t rep. The decimal32 type is not layout compatible with it's int32_t rep).
  • column_device_view::has_element_accessor<T>() identifies if column_device_view::element<T>() has a valid overload.

Scatter was erroneously instantiating things like
column_view::begin<struct_view>().

Updated the specializations to ensure that unsupported types throw an
exception.
@github-actions github-actions bot added the libcudf Affects libcudf (C++/CUDA) code. label Mar 25, 2021
@jrhemstad
Copy link
Contributor Author

The following tests are now failing as a result of this change:

	 19 - FIXED_POINT_TEST (Failed)
	 20 - UNARY_TEST (Failed)
	 21 - ROUND_TEST (Failed)
	 22 - BINARY_TEST (Failed)

I suspect this is all due to the erroneous code paths taken in the JIT code.

@jrhemstad jrhemstad added non-breaking Non-breaking change bug Something isn't working labels Mar 25, 2021
@jrhemstad jrhemstad requested a review from codereport March 25, 2021 21:09
@jrhemstad
Copy link
Contributor Author

So the fixed_point_binary_operation ultimately calls into the "regular" binary_operation API here:

binops::jit::binary_operation(out_view, lhs, rhs, op, stream);

which calls into:
void binary_operation(mutable_column_view& out,
column_view const& lhs,
column_view const& rhs,
const std::string& ptx,
rmm::cuda_stream_view stream)

which calls get_data_ptr<decimal32/64>
.launch(out.size(),
cudf::jit::get_data_ptr(out),
cudf::jit::get_data_ptr(lhs),
cudf::jit::get_data_ptr(rhs));

and in my PR, that lands you here:
template <typename T>
std::enable_if_t<not is_rep_layout_compatible<T>(), const void*> operator()(
column_view const& view)
{
CUDF_FAIL("Invalid data type for JIT operation");
}

The binop API only knows how to access data through the column_view::data<T>(), but that doesn't work for decimalXX. It needs to go through the column_device_view::element<T> or operate on the device_storage_type<T>.

get_data_ptr was erroneously invoking
column_view::data<decimal32/64>().

As it happens, this ended up being okay
when the column did not have any offset as
column_view::data<int32>() and
column_view::data<decimal32>() will
return the same initial pointer when the
offset is zero. The problem occurs when you
attempt to advance this pointer, or if the
column had an offset (which internally will advance the pointer).
@jrhemstad
Copy link
Contributor Author

The fix in a4788a0 was to just use dispatch_storage_type.

@codecov
Copy link

codecov bot commented Mar 26, 2021

Codecov Report

Merging #7725 (4571a03) into branch-0.19 (7871e7a) will increase coverage by 0.65%.
The diff coverage is n/a.

❗ Current head 4571a03 differs from pull request most recent head f92d462. Consider uploading reports for the commit f92d462 to get more accurate results
Impacted file tree graph

@@               Coverage Diff               @@
##           branch-0.19    #7725      +/-   ##
===============================================
+ Coverage        81.86%   82.52%   +0.65%     
===============================================
  Files              101      101              
  Lines            16884    17458     +574     
===============================================
+ Hits             13822    14407     +585     
+ Misses            3062     3051      -11     
Impacted Files Coverage Δ
python/cudf/cudf/utils/gpu_utils.py 53.65% <0.00%> (-4.88%) ⬇️
python/cudf/cudf/core/column/lists.py 87.68% <0.00%> (-3.72%) ⬇️
python/cudf/cudf/core/column/decimal.py 92.95% <0.00%> (-1.92%) ⬇️
python/cudf/cudf/core/abc.py 87.23% <0.00%> (-1.14%) ⬇️
python/cudf/cudf/core/column/numerical.py 94.83% <0.00%> (-0.20%) ⬇️
python/cudf/cudf/core/column/column.py 87.61% <0.00%> (-0.15%) ⬇️
python/cudf/cudf/utils/utils.py 85.36% <0.00%> (-0.07%) ⬇️
python/cudf/cudf/io/feather.py 100.00% <0.00%> (ø)
python/cudf/cudf/utils/ioutils.py 78.71% <0.00%> (ø)
python/cudf/cudf/comm/serialize.py 0.00% <0.00%> (ø)
... and 45 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e73fff0...f92d462. Read the comment docs.

@jrhemstad jrhemstad requested a review from trxcllnt March 29, 2021 17:39
@jrhemstad
Copy link
Contributor Author

I'm calling this "non-breaking" in that it doesn't change any external APIs. It technically could change externally visible behavior where some code will throw where it used to "work", but those use cases were broken code to begin with.

@@ -31,6 +31,7 @@
#include <type_traits>
#include "../fixture/benchmark_fixture.hpp"
#include "../synchronization/synchronization.hpp"
#include "cudf/utilities/traits.hpp"
Copy link
Contributor

@mythrocks mythrocks Mar 29, 2021

Choose a reason for hiding this comment

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

Nitpick: Aren't we enforcing angle brackets <> for includes that aren't in the current directory?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, something in my vscode auto includes headers and uses " instead of <>. I'll need to see if I can change that.

Copy link
Member

Choose a reason for hiding this comment

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

It's clangd IWYU.

Copy link
Contributor

@cwharris cwharris left a comment

Choose a reason for hiding this comment

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

nice!

Copy link
Contributor

@vyasr vyasr left a comment

Choose a reason for hiding this comment

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

Looks good to me. One request (if you don't want to do it then just re-request my review and I can approve): it seems like there are a number of places in this PR that are still using the raw std::enable_if_t<...>* = nullptr to disable implementations (where it's using an non-type template parameter that's unused AFAICT). Since any code patterns introduced here will inevitably be copied into other places and your new CUDF_ENABLE_IF macro is a bit cleaner, it would be nice to use it consistently everywhere as much as possible.

@jrhemstad
Copy link
Contributor Author

jrhemstad commented Mar 29, 2021

Looks good to me. One request (if you don't want to do it then just re-request my review and I can approve): it seems like there are a number of places in this PR that are still using the raw std::enable_if_t<...>* = nullptr to disable implementations (where it's using an non-type template parameter that's unused AFAICT). Since any code patterns introduced here will inevitably be copied into other places and your new CUDF_ENABLE_IF macro is a bit cleaner, it would be nice to use it consistently everywhere as much as possible.

Yeah, I got half way through and got sick of typing, so I made the macro. I was hoping reviewers would just let me be lazy :) But I agree, I'll go make stuff in this PR consistent.

Copy link
Contributor

@codereport codereport left a comment

Choose a reason for hiding this comment

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

Looks awesome! Small header things but not a big deal.

cpp/src/copying/copy.cu Outdated Show resolved Hide resolved
cpp/src/interop/dlpack.cpp Outdated Show resolved Hide resolved
cpp/src/jit/type.cpp Outdated Show resolved Hide resolved
@@ -28,6 +28,7 @@
#include <cudf/scalar/scalar.hpp>

#include <rmm/cuda_stream_view.hpp>
#include "cudf/utilities/traits.hpp"
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
#include "cudf/utilities/traits.hpp"
#include <cudf/utilities/traits.hpp>

@jrhemstad jrhemstad requested a review from vyasr March 29, 2021 21:38
Copy link
Contributor

@vyasr vyasr left a comment

Choose a reason for hiding this comment

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

Looks good!

@harrism harrism added the 5 - Ready to Merge Testing and reviews complete, ready to merge label Mar 30, 2021
@harrism
Copy link
Member

harrism commented Mar 30, 2021

@gpucibot merge

@rapids-bot rapids-bot bot merged commit 2d24a9b into rapidsai:branch-0.19 Mar 30, 2021
rapids-bot bot pushed a commit that referenced this pull request Apr 1, 2021
In #7725 I updated some of the fall through error cases to use old, [C-style ellipsis variadics ](https://github.com/jrhemstad/cudf/blob/f92d4626c7a4296075c5aa6240d6e3b88049abe6/cpp/include/cudf/detail/gather.cuh#L145 
)since we don't care about the parameters in the error case. Turns out C++ forbids passing "non-POD" types through this kind of variadic ellipsis, which ends up generating a compiler warning:

> warning: non-POD class type passed through ellipsis

Authors:
  - Jake Hemstad (https://github.com/jrhemstad)

Approvers:
  - David Wendt (https://github.com/davidwendt)
  - Nghia Truong (https://github.com/ttnghia)
  - Mark Harris (https://github.com/harrism)

URL: #7781
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
5 - Ready to Merge Testing and reviews complete, ready to merge bug Something isn't working libcudf Affects libcudf (C++/CUDA) code. non-breaking Non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Templated data accessors in column_view should not work with non-fixed-width types.
7 participants