search for: scevopaqueexpr

Displaying 4 results from an estimated 4 matches for "scevopaqueexpr".

2015 Aug 17
2
RFC for a design change in LoopStrengthReduce / ScalarEvolution
...pointers). All of the "this i64 register is actually a zero extended i32 register" can then be made to live within this `Register` class, making the structure of the code more obvious. # Within ScalarEvolution Another way to fix the problem is to introduce a new kind of SCEV node -- a `SCEVOpaqueExpr`. `SCEVOpaqueExpr` wraps another SCEV expression, and prevents optimizations from optimizing across the `SCEVOpaqueExpr` boundary. This will allow us to keep representing registers as SCEV pointers as they are today while solving the zext representation problem. After factoring a SCEV expression...
2015 Aug 17
4
RFC for a design change in LoopStrengthReduce / ScalarEvolution
...r as a native wide value) and you'd have to search over the possible interpretations of a specific solution. > Adding simplification barriers into SCEV expressions seems like a > dangerous idea, especially since LSR is not the only user of SCEV. So I don't intend for SCEV to produce SCEVOpaqueExpr nodes itself. There would instead be a 'const SCEV *getOpaqueExpr(const SCEV *)' function that clients of SCEV can use to create an opaque expression. Then most of the simplification routines SCEV will be changed to have the moral equivalent of 'if (isa<SCEVOpaqueExpr>(E)) continu...
2015 Aug 18
2
RFC for a design change in LoopStrengthReduce / ScalarEvolution
...gt; Sure, but fixing LSR by creating a local-handicapping mechanism for > SCEV seems somehow unfortunate. Are we going to oscillate from picking > from one part of the solution space to picking from a different part, > without particular regard for which might be better? While I found the SCEVOpaqueExpr idea easier to reason with, by no means am I suggesting that it is clearly the better solution. :) Would you rather this be solved fully within LSR instead? -- Sanjoy
2015 Aug 17
2
RFC for a design change in LoopStrengthReduce / ScalarEvolution
> To back up for a second, how much of this is self-inflicted damage? > IndVarSimplify likes to preemptively widen induction variables. Is > that why you have the extensions here in the first place? In the specific example I was talking about the zext came from our frontend (our FE used to insert these extensions for reasons that are no longer relevant). But you can easily get the same