llvm dev - Feb 2009 - [LLVMdev] overflow + saturation stuff

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

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

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?

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.

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