Displaying 3 results from an estimated 3 matches for "pr16130".
Did you mean:
616130
2013 Jun 24
1
[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its
On Jun 24, 2013, at 2:32 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> I assume that we're taking about nsw, etc. The fact that SCEV assumes nsw in some cases has led to problems (PR16130 has some history on this), and I don't understand why SCEV's unique-ifying/commoning expressions implies that it needs to drop the flags.
Yes I am talking about the ability to maintain nsw/nuw on general expressions between LLVM IR and the SCEV IR and back.
If I recall Andy’s explanation...
2013 Jun 24
0
[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its
...this is that this is not really something we
> can fix easily because of the way that SCEV works
> (unique-ifying/commoning expressions and thereby dropping the
> flags).
I assume that we're taking about nsw, etc. The fact that SCEV assumes nsw in some cases has led to problems (PR16130 has some history on this), and I don't understand why SCEV's unique-ifying/commoning expressions implies that it needs to drop the flags. Maybe this is just a matter of someone needing to do the work? Is it clear whether (i + 5 == i +(nsw) 5) should always be true, always false, or it depen...
2013 Jun 24
8
[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its
Hi,
I wanted to start a discussion about the following issue since I am not sure about what to do about it:
The loop-vectorizer has the potential to make code a quite a bit bigger (esp. in cases where we don’t know the loop count or whether pointers alias).
Chandler has observed this in snappy where we have a simple memory copying loop (that may overlap).
We vectorize this loop and then this