[LLVMdev] overflow + saturation stuff

[Chris Lattner]

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