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

[TIR][Arith] Add more strict checking in imm construction and folding. #12515

Merged
merged 9 commits into from
Sep 9, 2022

Conversation

wrongtest-intellif
Copy link
Contributor

@wrongtest-intellif wrongtest-intellif commented Aug 20, 2022

Refer to issues #12377 and #12378. The behavior of compile time constant folding and general path computation differs.

The changes are:

  • Add more strict value range checking when build IntImm object.

  • For constant folding on integers

    • Mimic intN arithmetic on intN folding, instead of direct int64 arithmetic.
  • For constant folding on floats

    • Only support float32 and float64, use float32 arithmetic on float32 folding, instead of float64 arithmetic.
    • Temporarily forbid fold float16 since we do not have implemented fp16 arithmetics yet and there may exist compatibility issues on different targets.

cc @junrushao1994

@wrongtest-intellif wrongtest-intellif force-pushed the make_more_strict_imm_check branch from 44624e5 to 0375ec5 Compare August 20, 2022 15:42
@wrongtest-intellif wrongtest-intellif force-pushed the make_more_strict_imm_check branch from 0375ec5 to 4240d54 Compare August 20, 2022 16:06
@@ -911,7 +911,9 @@ inline PrimExpr MakeConstScalar(DataType t, ValueType value, Span span = Span())
if (t.is_uint()) {
// Use IntImm if it is a small integer
uint64_t uval = static_cast<uint64_t>(value);
if (uval <= static_cast<uint64_t>(std::numeric_limits<int64_t>::max())) {
if (static_cast<int64_t>(value) < 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe here we should do value < static_cast<ValueType>(0). Because if value is of uint64_t, it will be regarded as a negative number if it is greater than numeric_limits<int64_t>::max().

@wrongtest-intellif wrongtest-intellif force-pushed the make_more_strict_imm_check branch from f1719af to 5e5d84d Compare August 24, 2022 16:40
@wrongtest-intellif wrongtest-intellif force-pushed the make_more_strict_imm_check branch from 74aaa1c to 9f85312 Compare August 28, 2022 13:26
@wrongtest-intellif wrongtest-intellif force-pushed the make_more_strict_imm_check branch 2 times, most recently from 22db840 to 13aa737 Compare August 29, 2022 06:09
@wrongtest-intellif wrongtest-intellif force-pushed the make_more_strict_imm_check branch from 13aa737 to f900f81 Compare August 29, 2022 10:55
@wrongtest-intellif
Copy link
Contributor Author

cc @ganler Hi, could you kindly take another look at the change~?

Copy link
Contributor

@ganler ganler left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks, @wrongtest-intellif for the great effort.

Copy link
Member

@junrushao junrushao 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 tremendous amount of work improving IntImm semantics! This is indeed super helpful and preventative of potential flaws at all levels of the system :-)

On the other hand, now that we have stronger enforcement of more formal semantics, it's entirely possible that some models might stop working due to our fix to this UB.

Therefore, I would suggest that we leave this PR open for 3 days, and if there is no objection, please feel free to merge it in yourself @wrongtest-intellif!

@vinx13 vinx13 merged commit 029fa46 into apache:main Sep 9, 2022
junrushao pushed a commit that referenced this pull request Sep 15, 2022
This change tries to fix an issue due to #12515.

Previously the logic for `-2147483648` is  `parse(-literal)` = `-parse(literal)`, and all integer literals are converted to i32 (either the literal value actually overflow or not).

Since after #12515, parse `2147483648` results in an i64 typed integer rather than i32, `-2147483648` then becomes an i64 integer too, which is not reasonable.
xinetzone pushed a commit to daobook/tvm that referenced this pull request Nov 25, 2022
apache#12515)

* Add more strict check in tir imm construction and folding.

* fix bool-compare compile error

* fix some illegal imm construction in testcases

* do not test i64 overflow behaviour because it is not consistent on cython and ctypes

* fix float32 testcase

* auto-inferred dtype should be int64 when value exceeds int32 range

* add floatimm range check for fp16 and fp32

* add more folding testcases and fix store fp32 folding result to double

* fix i386 fp16 cases
xinetzone pushed a commit to daobook/tvm that referenced this pull request Nov 25, 2022
This change tries to fix an issue due to apache#12515.

Previously the logic for `-2147483648` is  `parse(-literal)` = `-parse(literal)`, and all integer literals are converted to i32 (either the literal value actually overflow or not).

Since after apache#12515, parse `2147483648` results in an i64 typed integer rather than i32, `-2147483648` then becomes an i64 integer too, which is not reasonable.
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.

4 participants