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

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.

On Feb 9, 2009, at 9:18 AM, Paul Schlie wrote:
> 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.
Paul, I have a really hard time understanding what you're getting at.   
Please break down questions into multiple sentences: this entire  
paragraph is one sentence.

"Undefined on overflow" is an assertion to the optimizer that  
"something" knows that overflow can't happen.  This gives it
license
to optimized based on the assumption that overflow doesn't happen.
>
>
>>> 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?
I'm not sure what you're asking.  Please ask short and direct questions.
>>> 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)?
I'm not sure what level of selection you're talking about here.  We  
don't do selection on LLVM IR, we do it on the SelectionDAG data  
structure.  Are you asking how a target author would map a saturating  
add to a specific target instruction that does that operation?

-Chris