[LLVMdev] RFC: Integer saturation intrinsics

[Alasdair Grant]

> The plan is to form calls to these intrinsics in InstCombine. Legalizer
> can expand these intrinsics if they are not legal. The expansion should
> be fairly straight forward and produce code that is at least as good as
> what LLVM is currently generating for these code sequence.

SSAT/USAT may set the Q (saturation) flag, which might cause problems
for anyone relying on explicitly using saturating operations (QADD etc.)
and testing the Q flag.  So there are several possibilities:

 - you could do liveness analysis on Q and only introduce SSAT/USAT if
   Q is not live

 - you could fall back to not introducing SSAT/USAT if you could tell there
   was no test of Q in the function (the ARM ABI says Q is not defined across
   ABI-compliant function boundaries)

 - you could just go ahead and do it anyway (might be appropriate for a
   "fast and loose" optimization mode)

If you can easily factor Q into LLVM's liveness analysis, that might be
the best solution.  (It also allows you to discard the instruction if
neither its result nor the Q flag is tested - you can't normally drop
Q-flag-affecting instructions as they may be executed for side effects).

There are similar issues with some other ARM instructions, e.g. SMLABB.

Q is a sticky bit, like the floating-point cumulative exception flags,
so the issues are a bit similar (the same issue would apply if e.g. you
wanted to exploit floating-point hardware for integer division in a mode
where the inexact exception was valid).  You have the same issues of
modelling the use of machine status flags, and understanding what
optimizations are/aren't legal at any program point.

Al

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.