# Reference Manual Clarifications

Here are some clarifications for the reference manual. Please verify that my assumptions are correct. Shall I post a patch?

Floating-point Constants: Add "The assembler requires the exact decimal value of a floating-point constant. For example, the assembler accepts '1.25' but rejects '1.3' because '1.3' is a repeating decimal in binary."

Binary Operations: Add "of the same type" after "They require two operands".

Binary Operations: Replace "The result value of a binary operator is not necessarily the same type as its operands" with "The result value has the same type as its operands".

udiv/sdiv Instruction: Add "rounded towards zero" after "quotient of the two operands".

urem Instruction: Remove "regardless of whether the arguments are
unsigned or not" because it doesn't make sense. Using urem instead of srem asserts that the arguments are unsigned.

urem/srem Instruction: Move remainder/modulo discussion from srem to urem since many readers will read the document from top to bottom.
In any case, both instructions should state "result has the same sign as the dividend".

frem Instruction: There are four ways to define frem based on the rounding mode. The 8087 provides two of these: fprem and fprem1. Assuming the instruction uses the round-to-zero version of frem, add "calculated as <var1>-<var2>*floor(<var1>/<var2>)"

Bitwise Binary Operations: Add "of the same type" after "They require two operands"

Bitwise Binary Operations: Replace "The resulting value of the bitwise binary operators is always the same type as its first operand." with "The resulting value is the same type as its operands".

shl Instruction: Replace "var1 * 2^var2" with "var1 * 2^var2 mod 2^n, where n is width of result"

shl/lshr/ashr: Add "If var2 is negative, the result is undefined"

That's all for now.

Best Regards,
Jon

Concerning the shift instructions:

In C, the effect of shifting by any amount larger than the operand width
is undefined. In the design of the IR, either these operations need to
be explicitly stated as undefined or a well-defined value needs to be
established for them.

Concrete example:

What does a left shift of an i32 by 33 bits produce?

The risk of making these operations defined is that we may become
obligated to introduce conditional branches in the back end to check
that registerized shift amounts are not out of range w.r.t. what the
hardware can handle.

shap

shap

Here are some clarifications for the reference manual. Please verify
that my assumptions are correct. Shall I post a patch?

Floating-point Constants: Add "The assembler requires the exact decimal
value of a floating-point constant. For example, the assembler accepts
'1.25' but rejects '1.3' because '1.3' is a repeating decimal in binary."

yep

Binary Operations: Add "of the same type" after "They require two operands".

yep

Binary Operations: Replace "The result value of a binary operator is not
necessarily the same type as its operands" with "The result value has
the same type as its operands".

yep

udiv/sdiv Instruction: Add "rounded towards zero" after "quotient of the
two operands".

right.

urem Instruction: Remove "regardless of whether the arguments are
unsigned or not" because it doesn't make sense. Using urem instead of
srem asserts that the arguments are unsigned.

yep.

urem/srem Instruction: Move remainder/modulo discussion from srem to
urem since many readers will read the document from top to bottom.
In any case, both instructions should state "result has the same sign as
the dividend".

Ok.

frem Instruction: There are four ways to define frem based on the
rounding mode. The 8087 provides two of these: fprem and fprem1.
Assuming the instruction uses the round-to-zero version of frem, add
"calculated as <var1>-<var2>*floor(<var1>/<var2>)"

frem is defined to be exactly equal to the libm 'fmod' function.

Bitwise Binary Operations: Add "of the same type" after "They require
two operands"

ok

Bitwise Binary Operations: Replace "The resulting value of the bitwise
binary operators is always the same type as its first operand." with
"The resulting value is the same type as its operands".

right

shl Instruction: Replace "var1 * 2^var2" with "var1 * 2^var2 mod 2^n,
where n is width of result"

ok

shl/lshr/ashr: Add "If var2 is negative, the result is undefined"

if the value has is >= the size of the type, the result is undefined as well.

Thanks Jon!

-Chris

Concrete example:

What does a left shift of an i32 by 33 bits produce?

it is undefined in the llvm ir.

The risk of making these operations defined is that we may become
obligated to introduce conditional branches in the back end to check
that registerized shift amounts are not out of range w.r.t. what the
hardware can handle.

There is no risk, out of range shifts are undefined in llvm ir.

-Chris