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
On Mon, 31 Mar 2008, Jon Sargeant wrote:> 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 -- http://nondot.org/sabre/ http://llvm.org/
On Mon, 31 Mar 2008, Jonathan S. Shapiro wrote:> 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 -- http://nondot.org/sabre/ http://llvm.org/