[llvm-dev] Working on FP SCEV Analysis

[Sanjoy Das via llvm-dev]

Hi,

Daniel Berlin wrote:
 >
 >     If we're interested in handling complex variants of A directly:
 >     computing trip counts, proving away predicates etc. without
 >     translating the loops to use integer IVs (perhaps because we can't
 >     legally do so), then I can see FP-SCEV as a reasonable
 >     implementation strategy, but it looks like the general consensus is
 >     that such cases are rare and generally not worth optimizing?
 >
 > Just to explicitly not include myself in that consensus: I'm withholding
 > a real view till I see *some* evidence one way or the other.

Actually, allow me to revise what I said:

"but it looks it isn't clear that such cases generally worth
optimizing?"

instead of

"but it looks like the general consensus is
that such cases are rare and generally not worth optimizing?"

In any case, I wasn't trying to have a strong opinion on whether A is
important or not, but was really trying to get at this: my intuition
is that an FP-enabled SCEV will be worth the effort only if we
ultimately want to make LLVM "handle complex variants of A directly".
I wouldn't to make SCEV smarter around FP (which will be a lot of
work, and add complexity through the analysis) and then stop at just
B, since I don't see why we'd need all of the simplification etc. SCEV
typically does if we just want to handle B-like cases.  I may be wrong
about the latter part, and if I am, I'd like to know what teaching
SCEV about FP enables you to do in cases like B that are difficult to
do without FP-SCEV.

-- Sanjoy