[all-commits] [llvm/llvm-project] ab93c1: [LoopVectorize] use IR fast-math-flags exclusively...

[RotateRight via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ab93c18c125f0ee51959ef225fa8f09f4dc29e35
      https://github.com/llvm/llvm-project/commit/ab93c18c125f0ee51959ef225fa8f09f4dc29e35
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2021-01-27 (Wed, 27 Jan 2021)

  Changed paths:
    M llvm/include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h
    M llvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/lib/Transforms/Vectorize/VPlan.h
    M llvm/test/Transforms/LoopVectorize/X86/float-induction-x86.ll
    M llvm/unittests/Transforms/Vectorize/VPlanTest.cpp

  Log Message:
  -----------
  [LoopVectorize] use IR fast-math-flags exclusively (not FP function attributes)

I am trying to untangle the fast-math-flags propagation logic
in the vectorizers (see a6f022127 for SLP).

The loop vectorizer has a mix of checking FP function attributes,
IR-level FMF, and just wrong assumptions.

I am trying to avoid regressions while fixing this, and I think
the IR-level logic is good enough for that, but it's hard to say
for sure. This would be the 1st step in the clean-up.

The existing test that I changed to include 'fast' actually shows
a miscompile: the function only had the equivalent of nnan, but we
created new instructions that had fast (all FMF set). This is
similar to the example in https://llvm.org/PR35538

Differential Revision: https://reviews.llvm.org/D95452