[LLVMdev] Complex constant expressions?

Neil Booth neil at daikokuya.co.uk
Thu Jan 24 07:35:31 PST 2008


Talin wrote:-

> > Only two convert to integer.  The convertToAPInt is unfortunately
> > named; I'm not sure what it does but suspect it captures bitpatterns
> > like you suggest.
> >
> > convertToInteger is the function I'm responsible for and it does
> > float->int conversion according to IEEE754.  If you want to place
> > it in an APInt, create your APInt with the appropriate size and
> > use its buffer as input.  APInt has made unfortunate sign choices
> > though, IIRC it is not sign-extended, so you may need to fudge in
> > the case of a signed target.  This is also why there are two "from"
> > functions above :(
> >   
> OK here's a follow-up question: So far the ConstantExpr class has been 
> doing what I want pretty well. However, I'd like to be able to detect 
> overflow / loss of precision when casting constant values so that I can 
> issue the appropriate warning. Since the values are constant, I ought to 
> be able to tell whether or not they can "fit" in the destination type 
> without loss. For ints, this is easy enough using getActiveBits(). For 
> floats, I guess I would need to know whether the fractional part of the 
> number is zero or not, and I'd need floating-point equivalents to the 
> various integer min and max values, so that I could compare them with 
> the APFloat.
> 
> What would be a good technique for accomplishing this?

The APFloat functionality I wrote is the only means I'm aware of
in LLVM, via the return value.  APFloat is derived from C code I
wrote for my own C compiler front end, which catches and diagnoses
these constant-folding issues.  It, in C, has a different implementation
of APInt that additionally provides this information for integer
operations, like APFloat does for floating operations, making this
kind of analysis easy.  The static methods of APInt are essentially
part of that.

If LLVM's APFloat wrapper isn't conveying the info it is given
by APFloat, it needs to be improved :)

Neil.



More information about the llvm-dev mailing list