[LLVMdev] overflow + saturation stuff

[Chris Lattner]

On Feb 8, 2009, at 5:54 PM, Paul Schlie wrote:

> Are overflow behavior tags meant to enable the specification of a
> particular instruction's required or presumed overflow behavior?

I'm not sure what you mean.  The overflow tags specify what happens if  
overflow happens (defined wrapping, defined saturating, or undefined  
behavior), not *when* overflow happens.

> If a required overflow behavior, then it follows that the target must
> correspondingly implement the behavior; neither natively or emulated?

yes, if a target doesn't support saturation, it must emulate it.  This  
is the same as targets that doesn't support rem natively (e.g. ppc).

> If a presumed overflow behavior, is the target meant to preferably  
> implement
> or emulate the same; or is it merely meant to enable optimizations  
> which may
> or may not be representative of the code's target mapped behavior?
> Regardless, if the target is potentially meant to implement the  
> behavior;
> it follows that LLVM's assembly level representation must be able to
> discriminate between operations having differing semantics specified?

I don't understand what you mean.

>
> For example processors like TI's C6X family DSP's support both  
> saturating
> and 2's-comp operations; and although likely less frequently  
> required, and
> typically not directly supported by any HLL languages, being able to  
> specify
> target neutral in-line assembly 1's-comp end-around-carry operations  
> can be
> helpful on occasion, so would be nice to see as well.

I'm trying to increase the scope of what llvm can reason about and  
solve some specific problems, not solve every theoretical problem.

-Chris