overflow + saturation stuff

Chris Lattner 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)?

Chris Lattner 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