elementwise_util: don't cast the result of compute_fun back to the common type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type

[swolchok]

The compute function might return an entirely different type. For
example, if we were applying a trigonometric function like acos to an
input of type bool expecting an output of type float, we would get bad
results because acos(0) = 1.57, but casting through bool would
truncate that to 1.

Note that we don't need the pair of ET_CHECK_MSG I removed because we
already check tensor dtypes on entry to the elementwise util
functions; the checks were inconvenient because we now call
get_store_common_to_tensor_fn without the actual common type.

[swolchok]

Stack from ghstack (oldest at bottom):

• NOCOMMIT: PoC: vectorize just expm1 #9586
• relax tolerances for all unary float ops #9585
• Add vectorization in elementwise_util #9432
• BroadcastIndexesRange: leading 1s don't require true broadcasting #9431
• RFC: Specialize for non-mixed-dtype in elementwise_util #9388
• Add SupportedTensorDtypes::BOOL #9584
• Refactor elementwise_util: create variants with out_dtypes in template argument list #9387
• ->elementwise_util: don't cast the result of compute_fun back to the common type #9385
• Make PyTorch headers available in optimized_portable_kernels, define ET_USE_PYTORCH_HEADERS #9384

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9385

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job

As of commit f1c5429 with merge base 644b7dd ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

[swolchok]

hmm, don't understand why unittest / macos is failing on CI but not locally. maybe PR is out of sync? rebasing

There was an ASAN failure, which is now fixed.

[swolchok]

need to add a regression test for acos case as well

[manuelcandales]

why do you need ignore_first_yield_second? why not use CTYPE_COMMON directly in here?

[swolchok]

because I need the ... to produce sizeof...(Args) instances of CTYPE_COMMON. If you have a suggestion for a better way to do that I would love to hear it; this is the best I could do.

[swolchok]

this breaks mul(int8, int8, out=long). I think we need to add a notion of "float ops" to the elementwise_util functions corresponding to TensorIterator's notion of "float ops", which essentially just means "set promote_integer_inputs_to_float to true".

[swolchok]

this diff has been removed from the stack it thinks it's in

[swolchok]

turns out this is unnecessary and the real problem is that "float ops" were not setting the compute dtype to a floating-point type