[LLVMdev] RFC: Integer saturation intrinsics

Evan Cheng evan.cheng at apple.com
Sun Jun 19 10:10:33 PDT 2011


CPSR liveness is not a concern. The instructions will be modeled as such and isel and scheduling will do the right thing.

Evan

On Jun 18, 2011, at 1:48 AM, Alasdair Grant wrote:

>> 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.
> 




More information about the llvm-dev mailing list