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