Stream: git-cranelift

Topic: cranelift / Issue #1401 Allow parsing of hexadecimal imme...


view this post on Zulip GitHub (Feb 21 2020 at 18:45):

abrown opened Issue #1401:

<!-- Please try to describe precisely what you would like to do in Cranelift and/or
expect from it. You can answer the questions below if they're relevant and
delete this text before submitting. Thanks for opening an issue! -->

Feature

<!-- What is the feature or code improvement you would like to do in Cranelift? -->

The types i16, i32, and i64 currently cannot be parsed from a hexadecimal integer; i8 can by using the match_uimm8 function in parser.rs but match_imm16, match_imm32, and match_imm64 do not allow this.

Benefit

<!-- What is the value of adding this in Cranelift? -->

At times we are forced to use strange negative numbers to represent values more naturally expressed with a hexadecimal number; e.g. when preparing a value for checking overflow semantics in a 16-bit vector lane, it is more convenient to use 0xffff than -32768.

Implementation

<!-- Do you have an implementation plan, and/or ideas for data structures or algorithms to use? -->

Alternatives

<!-- Have you considered alternative implementations? If so, how are they better or worse than your proposal? -->

We could leave this as is; it makes sense that the match_imm* functions are concerned primarily with parsing signed integers. However, adding hexadecimal parsing would not break anything as long as we include checks that the number has no more bits than necessary (e.g. a hex number parsed to an Imm64 should have no more than 64 bits).

view this post on Zulip GitHub (Feb 28 2020 at 23:28):

alexcrichton transferred Issue #1401:

<!-- Please try to describe precisely what you would like to do in Cranelift and/or
expect from it. You can answer the questions below if they're relevant and
delete this text before submitting. Thanks for opening an issue! -->

Feature

<!-- What is the feature or code improvement you would like to do in Cranelift? -->

The types i16, i32, and i64 currently cannot be parsed from a hexadecimal integer; i8 can by using the match_uimm8 function in parser.rs but match_imm16, match_imm32, and match_imm64 do not allow this.

Benefit

<!-- What is the value of adding this in Cranelift? -->

At times we are forced to use strange negative numbers to represent values more naturally expressed with a hexadecimal number; e.g. when preparing a value for checking overflow semantics in a 16-bit vector lane, it is more convenient to use 0xffff than -32768.

Implementation

<!-- Do you have an implementation plan, and/or ideas for data structures or algorithms to use? -->

Alternatives

<!-- Have you considered alternative implementations? If so, how are they better or worse than your proposal? -->

We could leave this as is; it makes sense that the match_imm* functions are concerned primarily with parsing signed integers. However, adding hexadecimal parsing would not break anything as long as we include checks that the number has no more bits than necessary (e.g. a hex number parsed to an Imm64 should have no more than 64 bits).


Last updated: Dec 23 2024 at 13:07 UTC