[PATCH] D128591: Transforms: refactor pow(x, n) expansion where n is a constant integer value

[David Sherwood via Phabricator via llvm-commits]

david-arm added a comment.

Hi @eaeltsin isn't this the same problem with every other FP optimisation where the user has explicitly requested optimisations to take place? The same thing is true for stuff like the following:

  float __attribute__((optnone)) reduc1(float *src, long n) {
    float r = 0;
    for (long i = 0; i < n; i++)
      r += src[i];
    return r;
  }
  
  float reduc2(float *src, long n) {
    float r = 0;
    for (long i = 0; i < n; i++)
      r += src[i];
    return r;
  }

and the user compiles with -Ofast. With certain pathological cases it's also possible to produce quite different results. It seems to me that if the user has explicitly requested FP optimisations (because they care more about performance than accuracy) and the optimisations are legal within the context of the flags requested, then the compiler is doing the right thing?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128591/new/

https://reviews.llvm.org/D128591