Here is a patch containing all but one of the changes. I realized that the remainder/modulo discussion does indeed belongs to the srem instruction. The semantics of urem are obvious and need no further clarification. Best Regards, Jon 1572,1573c1572,1575 < notation (see below). Floating point constants must have a <a < href="#t_floating">floating point</a> type. </dd> --- > notation (see below). 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. Floating point > constants must have a <a href="#t_floating">floating point</a> type. </dd> 2178c2180 < program. They require two operands, execute an operation on them, and --- > program. They require two operands of the same type, execute an operation on them, and 2181,2182c2183 < The result value of a binary operator is not < necessarily the same type as its operands.</p> --- > The result value has the same type as its operands.</p> 2332c2333 < <p>The value produced is the signed integer quotient of the two operands.</p> --- > <p>The value produced is the signed integer quotient of the two operands rounded towards zero.</p> 2386,2387c2387 < This instruction always performs an unsigned division to get the remainder, < regardless of whether the arguments are unsigned or not.</p> --- > This instruction always performs an unsigned division to get the remainder.</p> 2458c2458,2459 < <p>This instruction returns the <i>remainder</i> of a division.</p> --- > <p>This instruction returns the <i>remainder</i> of a division. > The remainder has the same sign as the dividend.</p> 2472,2474c2473,2474 < instructions. They require two operands, execute an operation on them, < and produce a single value. The resulting value of the bitwise binary < operators is always the same type as its first operand.</p> --- > instructions. They require two operands of the same type, execute an operation on them, > and produce a single value. The resulting value is the same type as its operands.</p> 2499,2501c2499,2501 < <p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup>. If < <tt>var2</tt> is (statically or dynamically) equal to or larger than the number < of bits in <tt>var1</tt>, the result is undefined.</p> --- > <p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup> mod 2<sup>n</sup>, > where n is the width of the result. If <tt>var2</tt> is (statically or dynamically) negative or > equal to or larger than the number of bits in <tt>var1</tt>, the result is undefined.</p> 2532c2532 < shift. If <tt>var2</tt> is (statically or dynamically) equal to or larger than --- > shift. If <tt>var2</tt> is (statically or dynamically) negative or equal to or larger than 2567c2567 < of <tt>var1</tt>. If <tt>var2</tt> is (statically or dynamically) equal to or --- > of <tt>var1</tt>. If <tt>var2</tt> is (statically or dynamically) negative or equal to or
Hi Jon, Please you'll want to submit patches as unified diffs and as attachments. I notice you're using Thunderbird, so I refer you to this tip: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/011992.html Although this note doesn't apply to how you included your original patch (looks like you pasted it in), Thunderbird has default attachment handling settings which cause problems for many of our reviewers. Thanks, Gordon On Mar 31, 2008, at 15:17, Jon Sargeant wrote:> Here is a patch containing all but one of the changes. I realized > that > the remainder/modulo discussion does indeed belongs to the srem > instruction. The semantics of urem are obvious and need no further > clarification. > > Best Regards, > Jon > > 1572,1573c1572,1575 > < notation (see below). Floating point constants must have a <a > < href="#t_floating">floating point</a> type. </dd> > --- >> notation (see below). 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. Floating > point >> constants must have a <a href="#t_floating">floating point</a> > type. </dd> > 2178c2180 > < program. They require two operands, execute an operation on them, > and > --- >> program. They require two operands of the same type, execute an > operation on them, and > 2181,2182c2183 > < The result value of a binary operator is not > < necessarily the same type as its operands.</p> > --- >> The result value has the same type as its operands.</p> > 2332c2333 > < <p>The value produced is the signed integer quotient of the two > operands.</p> > --- >> <p>The value produced is the signed integer quotient of the two > operands rounded towards zero.</p> > 2386,2387c2387 > < This instruction always performs an unsigned division to get the > remainder, > < regardless of whether the arguments are unsigned or not.</p> > --- >> This instruction always performs an unsigned division to get the > remainder.</p> > 2458c2458,2459 > < <p>This instruction returns the <i>remainder</i> of a division.</p> > --- >> <p>This instruction returns the <i>remainder</i> of a division. >> The remainder has the same sign as the dividend.</p> > 2472,2474c2473,2474 > < instructions. They require two operands, execute an operation on > them, > < and produce a single value. The resulting value of the bitwise > binary > < operators is always the same type as its first operand.</p> > --- >> instructions. They require two operands of the same type, execute an > operation on them, >> and produce a single value. The resulting value is the same type as > its operands.</p> > 2499,2501c2499,2501 > < <p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></ > sup>. If > < <tt>var2</tt> is (statically or dynamically) equal to or larger than > the number > < of bits in <tt>var1</tt>, the result is undefined.</p> > --- >> <p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup> > mod 2<sup>n</sup>, >> where n is the width of the result. If <tt>var2</tt> is (statically > or dynamically) negative or >> equal to or larger than the number of bits in <tt>var1</tt>, the > result is undefined.</p> > 2532c2532 > < shift. If <tt>var2</tt> is (statically or dynamically) equal to or > larger than > --- >> shift. If <tt>var2</tt> is (statically or dynamically) negative or > equal to or larger than > 2567c2567 > < of <tt>var1</tt>. If <tt>var2</tt> is (statically or dynamically) > equal to or > --- >> of <tt>var1</tt>. If <tt>var2</tt> is (statically or dynamically) > negative or equal to or > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Gordon Henriksen wrote:> Hi Jon, > > Please you'll want to submit patches as unified diffs and as > attachments. > > I notice you're using Thunderbird, so I refer you to this tip: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/011992.html > > Although this note doesn't apply to how you included your original > patch (looks like you pasted it in), Thunderbird has default > attachment handling settings which cause problems for many of our > reviewers. > > Thanks, > GordonOk, did I get it right this time? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LangRef.html.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080331/47368f65/attachment.ksh>
The fptrunc instruction states "If the value cannot fit within the destination type, ty2, then the results are undefined." This is fine, but what about other floating-point operations that can overflow? For example, does 'mul double 1.0e300, 1.0e300' produce +infinity or is it undefined? I think LLVM should treat floating-point overflows consistently. On a similar note, what is the result of division by zero for fdiv? infinity or undefined? The manual needs to state the rounding mode of the fptrunc, uitofp, and sitofp instruction (if only to say it's undefined). I recommend round-to-nearest. What is the behavior of alloca if there is insufficient memory? null or undefined behavior? I'm attaching another round of changes. Please verify that they are correct. Best Regards, Jon -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: langref_changes2.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080331/a512272f/attachment.ksh>
> What is the behavior of alloca if there is insufficient memory? null or > undefined behavior?Undefined. Ciao, Duncan.
On Mon, 2008-03-31 at 20:59 -0700, Jon Sargeant wrote:> The manual needs to state the rounding mode of the fptrunc, uitofp, and > sitofp instruction (if only to say it's undefined). I recommend > round-to-nearest.Alternatively, the manual needs to admit the notion of rounding mode controls per IEEE floating point, and then define the instructions to operate according to IEEE.> What is the behavior of alloca if there is insufficient memory? null or > undefined behavior?While you are touching alloca docs, I had a discussion on IRC about it that should be added: alloca allocates storage from the stack, and is guaranteed not to trigger GC. This matters because on some systems the stack frames might be allocated from the heap. The alloca primitive assumes that this is not the case.
On Mon, 31 Mar 2008, Jon Sargeant wrote:> The fptrunc instruction states "If the value cannot fit within the > destination type, ty2, then the results are undefined." This is fine, but > what about other floating-point operations that can overflow? For example, > does 'mul double 1.0e300, 1.0e300' produce +infinity or is it undefined?It is defined by IEEE to be inf.> I > think LLVM should treat floating-point overflows consistently. On a similar > note, what is the result of division by zero for fdiv? infinity or > undefined?IEEE also specifies these, but I don't know the answer off-hand.> The manual needs to state the rounding mode of the fptrunc, uitofp, and > sitofp instruction (if only to say it's undefined). I recommend > round-to-nearest.Everything is implicitly assumed to be in the default rounding mode. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Mon, 31 Mar 2008, Jon Sargeant wrote:> I'm attaching another round of changes. Please verify that they are correct.Applied with edits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html I figured out what your patches don't apply. Something (your web browser, editor, etc) is stripping trailing whitespace. -Chris -- http://nondot.org/sabre/ http://llvm.org/