[LLVMdev] Reference Manual Clarifications

[Chris Lattner]

On Tue, 1 Apr 2008, Jon Sargeant wrote:
>> I removed the "negative or equal" aspect to the shift amount
>> discussion.  Shift amounts are interpreted as unsigned values, so they
>> can't be negative.
>
> Ah, I didn't see that in the documentation.  I suggest adding "Shift
> amounts are interpreted as unsigned values" to each shift instruction.

That would make sense.

>> Also, it looks like your copy of langref is slightly out of date,
>> because the patch didn't apply cleanly.
>
> Hmm, I copied LangRef.html from http://llvm.org/docs/LangRef.html.  The
> version I'm using was last modified 2008-03-24 15:52:42 -0500 (Mon, 24
> Mar 2008).  Perhaps there was a newer version on SVN?  In any case, I'll
> use the latest version from SVN for future patches.

I'm not really sure what is going on, but when I applied the patch, a 
couple hunks didn't go in.  *shrug*, in this case it was easy to fix up by 
hand.

>>> 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.

>Yes.  AFAIK, IEEE754 defines floating-point truncation also.  If a
>double-precision value is too large for single precision, the result
>is infinity (not undefined).

I would have to look this up, but the meta point stands: we should be very 
clear in langref what the actual semantics are :).

Incidentally, at some point I would like to generalize our FP support to 
better capture rounding modes and other information (to [e.g.] support the 
C99 numerics pragmas, -ffast-math, etc).  This is a long term project that 
isn't even very well formed at this point.  In the short term, correctly 
describing what we have is very important and useful.  Thank you for 
working on this!

>>> 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.

> After doing a quick search on Google, it looks like the default rounding
> mode is round to nearest.  Would the default rounding mode ever be
> different than round to nearest?

Nope, I think that stating the LLVM IR depends on that is fine.  Thanks 
again Jon,

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/