[LLVMdev] overflow + saturation stuff

[Paul Schlie]

Chris Lattner wrote:
> 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.

- Is undefined behavior meant to imply that if such condition were to
occur, the undefined behavior will be warranted to not be expressed as
it will be trapped; or merely assumed it won't occur and thereby may be
optimized based on this assumption, regardless of the behavior which may
actually be expressed in the absents of optimization if and when the
condition occurred (and thereby optimizations may legitimately alter
logical program behavior if sensitive to an otherwise expressible
undefined behavior), and thereby truly just an optimization tag.

>> If a required overflow behavior, then it follows that the target must
>> correspondingly implement the behavior; either 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).

- Thanks partially understood; as above, the tags seem to have multiple
intended purposes; on one hand to be used by optimizers but not affect the
instruction selection process; on the other hand must affect the selection
process as below?

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

- Sorry, merely meant: if an instruction's overflow behavior tag is meant
to affect target instruction selection semantics, it would seem necessary
to be selectable at the llvm assembly code level  (i.e. how does one specify
a saturating addition vs. 2's-comp addition instruction semantics at the
llvm assembly code level of representation)?

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