[llvm-dev] Working on FP SCEV Analysis

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Mon May 16 14:42:01 PDT 2016


[+CC Andy]

Hi Elena,

I don't have any fundamental issues with teaching SCEV about floating
point types, but given this will be a major change, I think a high
level roadmap should be discussed on llvm-dev before we start
reviewing and committing changes.

Here are some issues that I think are worth discussing:

  - Core motivation: why do we even care about optimizing floating
    point induction variables?  What situations are they common in?  Do
    programmers _expect_ compilers to optimize them well?  (I haven't
    worked on our vectorizers so pardon the possibly stupid question)
    in the example you gave, why do you need SCEV to analyze the
    increment to vectorize the loop (i.e how does it help)?  What are
    some other concrete cases you'll want to optimize?

  - I presume you'll want SCEV expressions for `sitofp` and `uitofp`.
    (The most important question:) With these in the game, what is the
    canonical representation of SCEV expressions that can be expressed
    as, say, both `sitofp(A + B)` and `sitofp(A) + sitofp(B)`?

    Will we have a way to mark expressions (like we have `nsw` and
    `nuw` for `sext` and `zext`) which we can distribute `sitofp` and
    `uitofp` over?

    Same questions for `fptosi` and `fptoui`.

  - How will you partition the logic between floating and integer
    expressions in SCEV-land?  Will you have, say, `SCEVAddExpr` do
    different things based on type, or will you split it into
    `SCEVIAddExpr` and `SCEVFAddExpr`? [0]

    * There are likely to be similarities too -- e.g. the "inductive"
      or "control flow" aspect of `SCEVAddRecExpr` is likely to be
      common between floating point add recurrences[1], and integer add
      recurrences; and part of figuring out the partitioning is also
      figuring out how to re-use these bits of logic.
	

[0]: I'll prefer the latter since e.g. integer addition is
associative, but floating point addition isn't; and it is better to
force programmers to handle the two operations differently.

[1]: For instance, things like this:
https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/ScalarEvolution.cpp#L7564
are likely to stay common between floating point and integer add recs.

-- Sanjoy


More information about the llvm-dev mailing list