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.

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