search for: int_smax

Hi, I observed below behavior with Instruction combiner (visitMul Canonicalization) It tries to convert "(X+C1)*C2" to "X*C2+C1*C2" While transforming if operation is guaranteed to not overflow it does not reflect same property to transformed instructions. Consider following scenarios: 1) If input is ((X+C1)*C2)<nsw> Then post canonicalization output should be

...exploit no-overflow, inbounds or exact > > Why? Can you provide an example using nsw, inbounds, etc.? I think the same case as the general UB applies: void foo(int n) available_externally { if (n s< (n +nsw 1)) abort(); } void bar() { if (< runtine cond always false>) foo(INT_SMAX); } Now foo() can be simplified to "ret void" using the nsw, and the call to foo(INT_SMAX) can be hoisted. This is a problem if we link to an unrefined @foo. -- Sanjoy

Hi, I am trying to understand the limitations of the current vectorizer, and came upon these test cases that fail to get vectorized. 1. loop1 below (note the increment by 2) fails to get vectorized because the access a[j+1] is considered to wrap around (the corresponding SCEV doesn't have nsw/nuw set) and hence isStridedPtr() in LoopAccessAnalysis.cpp return false. #define SIZE 100000 void

----- Original Message ----- > From: "Sanjoy Das" <sanjoy at playingwithpointers.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith"

...e from, is it from the source language definition, Or compiler derived analysis information ? Both are possible. In C/C++, as you know, most (all?) signed arithmetic can be marked nsw. In many cases the optimizer will also infer nsw if it can prove the arithmetic does not overflow (e.g. if (a != INT_SMAX) b = a + 1; ==> if (a != INT_SMAX) b = a+nsw 1;). -- Sanjoy Here’s the original source example for context ——————————————————————————————— [llvm-dev] RFC: Killing undef and spreading poison Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org Fri Nov 11 23:55:32 PST 2016 Firstly consider...

On Wed, Feb 24, 2016 at 11:18 PM, Hal Finkel <hfinkel at anl.gov> wrote: > It might be much more challenging, but let's try. This is not an > issue we need to fix by the end of the month, and the potential > optimization regressions are significant. Our deductions of > readonly/readnone/nocapture/etc. are really important for enabling > other optimizations. Given that all

Sanjoy, My answer is that step 3, commuting the multiply with the sign-extends, is invalid, As this is what causes the `udiv` to fault. I think it is invalid with or without the “freeze”, why do you think step 3, the commute, without the “freeze" is valid ? Also, do you think you can come up with an example that does not depend on signed overflow being “undefined” ? Peter