[llvm-dev] Floating Point SCEV Analysis

Andrew Trick via llvm-dev llvm-dev at lists.llvm.org
Mon May 30 11:40:01 PDT 2016


My response to this patch is below, but adding a floating-point feature to SCEV should really be hashed out on the llvm-dev list first. I would like to get the attention of floating-point experts on the design review.

I’d like to see a small design proposal justifying the feature and defending it’s soundness. My concern is that the approach may not be sound, but providing this core API would encourage llvm dev’s to use the feature without thinking.

I suggest starting with SCEV’s most basic functionality and proving the validity of increasingly complex cases. Can you defend SCEV’s ability to remove loops like this?

float fincby(float start, int N) {
  float result = start;
  for (int i = 0; i < N; ++i) {
    result += 1.0f;
  }
  return result;
}

-Andy

http://reviews.llvm.org/D20695

> Begin forwarded message:
> 
> From: Andrew Trick via llvm-commits <llvm-commits at lists.llvm.org>
> Subject: Re: [PATCH] D20695: Floating Point SCEV Analysis
> Date: May 30, 2016 at 11:05:35 AM PDT
> To: reviews+D20695+public+faa7820b5ed6aa91 at reviews.llvm.org
> Cc: llvm-commits at lists.llvm.org, mssimpso at codeaurora.org
> Reply-To: Andrew Trick <atrick at apple.com>
> 
> 
>> On May 30, 2016, at 12:02 AM, Sanjoy Das <sanjoy at playingwithpointers.com <mailto:sanjoy at playingwithpointers.com>> wrote:
>> 
>> I have made some minor comments inline, but I still stand by my earlier comment that we should do something like this as a last resort.  As an initial step we should at least evaluate how far we can we can get on relevant workloads without teaching SCEV about floating point values at all.
> 
> Are there conceivable use cases for this infrastructure beyond vectorizing a small subcategory of loops of this form?
> 
> float x = init;
>  for (int i=0;i<N;i++){
>    A[i] = x;
>    x += fp_inc; // Loop invariant variable or constant
>  }
> 
> Can the vectorizer handle loops of this form without querying SCEV?
> 
> SCEV expressions have an inherent width. They are not infinite precision. This is the main challenge of working with SCEV expressions, as Sanjoy is well aware. What happens when incrementing a floating-point SCEV expression by a smaller amount than ULP. Eventually that will happen in a floating-point recurrence. Do we have to prove that floating-point recurrences behave a certain way before we can legally convert them to SCEV expressions?
> 
> Honestly, I’m not an expert in floating-point semantics, and I wouldn’t feel comfortable adding this to SCEV without buy-in from someone who is.
> 
> Andy
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160530/911a5e2e/attachment.html>


More information about the llvm-dev mailing list