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

[PATCH] Fix undefined __floatdihf in libtvmruntime.so on aarch64. #4119

Merged
merged 1 commit into from
Oct 17, 2019

Conversation

lhutton1
Copy link
Contributor

@lhutton1 lhutton1 commented Oct 14, 2019

Arm architecture provides optional FP16 floating point support in two alternative formats, IEEE and an an alternative Arm format.

The ACLE (Arm C Language Extension) defined preprocessor symbol __ARM_FP16_FORMAT_IEEE can be used to distinguish between implementations providing IEEE and the Arm alternative format, but cannot, on its own, be used to determined if FP16 HW support is actually present.

Testing this preprocessor symbol can lead to undefined __floatdihf at runtime on an aarch64 target where no FP16 HW is present.

The relevant preprocessor symbol to determine whether FP16 HW support is present in the target is __ARM_FEATURE_FP16_SCALAR_ARITHMETIC, this symbol implies __ARM_FP16_FORMAT_IEEE.

The relevant preprocessor symbols are defined by the ACLE standard, section 5.5.21 16-bit floating-point data processing operations, https://static.docs.arm.com/101028/0008/Q2-ACLE_2019Q2_release-0008.pdf

Copy link
Contributor

@tmoreau89 tmoreau89 left a comment

Choose a reason for hiding this comment

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

Thanks @lhutton1 for the catch, and the fix.

Arm architecture provides optional FP16 floating point support in two alternative formats, IEEE and an an alternative Arm format.

The ACLE (Arm C Language Extension) defined preprocessor symbol __ARM_FP16_FORMAT_IEEE can be used to distinguish between implementations providing IEEE and the Arm alternative format, but cannot, on its own, be used to determined if FP16 HW support is actually present.

Testing this preprocessor symbol can lead to undefined __floatdihf at runtime on an aarch64 target where no FP16 HW is present.

The relevant preprocessor symbol to determine whether FP16 HW support is present in the target is __ARM_FEATURE_FP16_SCALAR_ARITHMETIC, this symbol implies  __ARM_FP16_FORMAT_IEEE.

The relevant preprocessor symbols are defined by the ACLE standard, section 5.5.21 16-bit floating-point data processing operations, https://static.docs.arm.com/101028/0008/Q2-ACLE_2019Q2_release-0008.pdf
@tqchen tqchen merged commit cf04697 into apache:master Oct 17, 2019
@tqchen
Copy link
Member

tqchen commented Oct 17, 2019

Thanks @tmoreau89 @lhutton1 !

anijain2305 pushed a commit to anijain2305/tvm that referenced this pull request Oct 17, 2019
…ache#4119)

Arm architecture provides optional FP16 floating point support in two alternative formats, IEEE and an an alternative Arm format.

The ACLE (Arm C Language Extension) defined preprocessor symbol __ARM_FP16_FORMAT_IEEE can be used to distinguish between implementations providing IEEE and the Arm alternative format, but cannot, on its own, be used to determined if FP16 HW support is actually present.

Testing this preprocessor symbol can lead to undefined __floatdihf at runtime on an aarch64 target where no FP16 HW is present.

The relevant preprocessor symbol to determine whether FP16 HW support is present in the target is __ARM_FEATURE_FP16_SCALAR_ARITHMETIC, this symbol implies  __ARM_FP16_FORMAT_IEEE.

The relevant preprocessor symbols are defined by the ACLE standard, section 5.5.21 16-bit floating-point data processing operations, https://static.docs.arm.com/101028/0008/Q2-ACLE_2019Q2_release-0008.pdf
wweic pushed a commit to neo-ai/tvm that referenced this pull request Oct 18, 2019
…ache#4119)

Arm architecture provides optional FP16 floating point support in two alternative formats, IEEE and an an alternative Arm format.

The ACLE (Arm C Language Extension) defined preprocessor symbol __ARM_FP16_FORMAT_IEEE can be used to distinguish between implementations providing IEEE and the Arm alternative format, but cannot, on its own, be used to determined if FP16 HW support is actually present.

Testing this preprocessor symbol can lead to undefined __floatdihf at runtime on an aarch64 target where no FP16 HW is present.

The relevant preprocessor symbol to determine whether FP16 HW support is present in the target is __ARM_FEATURE_FP16_SCALAR_ARITHMETIC, this symbol implies  __ARM_FP16_FORMAT_IEEE.

The relevant preprocessor symbols are defined by the ACLE standard, section 5.5.21 16-bit floating-point data processing operations, https://static.docs.arm.com/101028/0008/Q2-ACLE_2019Q2_release-0008.pdf
petrex added a commit to petrex/tvm that referenced this pull request Oct 29, 2019
* master: (51 commits)
  [QNN][TFLite] Parsing QNN Add op. Adding MobilenetV2. (apache#4142)
  [CI] Pin NNPack pthreadtools version (apache#4152)
  Fix typo (apache#4144)
  [Relay][Frontend][TF] Add tensor array ops (apache#3798)
  [relay][vm] Separate VM runtime with executable (apache#4100)
  [PATCH] Fix undefined __floatdihf in libtvmruntime.so on aarch64. (apache#4119)
  [DOCKER] Pin torchvision==0.4.1 (apache#4140)
  [TOPI][x86] Cascade lake support. (apache#4123)
  [Relay] Improve build error when no lowered funcs are produced (apache#4132)
  [RUNTIME] Refactor object python FFI to new protocol. (apache#4128)
  Update PULL_REQUEST_TEMPLATE.md
  Adding support for dequantizing from int32 to float32. (apache#4130)
  [Relay][Training] Add and fix gradients (apache#4126)
  [QNN] Change default rouning to UPWARD. (apache#4131)
  Fix infer type of kernel in dense. (apache#4125)
  [Relay][AlterOpLayout] NHWC to NCHWc pad operator. (apache#4103)
  [ARITH] Fix lowering of floormod(x, y) != 0 (apache#4127)
  [RFC][RUNTIME] Introduce new object protocol. (apache#4115)
  [Relay][Topi] Disable conv NHWC pack int8. (apache#4038)
  Update task_cpp_unittest.sh
  ...
@lhutton1 lhutton1 deleted the floatdihf branch July 8, 2020 14:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants