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?

Yes please.

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