search for: nsw

...define void @main(i64 %arg0, i64 %arg1, i64 %arg2, i1 %arg3, i64 %arg4, float* noalias %arg5, float* noalias %arg6, float* noalias %arg7, double* noalias %arg8) { entrypoint: br i1 %arg3, label %L0, label %L1 L0: ; preds = %entrypoint %0 = add nsw i64 %arg0, %arg4 %1 = add nsw i64 %arg1, %arg4 br label %L2 L1: ; preds = %entrypoint br label %L2 L2: ; preds = %L0, %L1 %2 = phi i64 [ %arg0, %L1 ], [ %0, %L0 ] %3 = phi i64 [ %arg1, %L1 ]...

...4 %arg1, i64 %arg2, i1 %arg3, i64 > %arg4, float* noalias %arg5, float* noalias %arg6, float* noalias > %arg7, double* noalias %arg8) { > entrypoint: > br i1 %arg3, label %L0, label %L1 > > L0: ; preds = %entrypoint > %0 = add nsw i64 %arg0, %arg4 > %1 = add nsw i64 %arg1, %arg4 > br label %L2 > > L1: ; preds = %entrypoint > br label %L2 > > L2: ; preds = %L0, %L1 > %2 = phi i64 [ %arg0, %L1 ], [ %0, %L...

...g3, i64 %arg4, >> float* noalias %arg5, float* noalias %arg6, float* noalias %arg7, double* >> noalias %arg8) { >> entrypoint: >> br i1 %arg3, label %L0, label %L1 >> >> L0: ; preds = %entrypoint >> %0 = add nsw i64 %arg0, %arg4 >> %1 = add nsw i64 %arg1, %arg4 >> br label %L2 >> >> L1: ; preds = %entrypoint >> br label %L2 >> >> L2: ; preds = %L0, %L1 >> %2 =...

...* noalias %arg5, float* noalias %arg6, float* > noalias %arg7, double* noalias %arg8) { > entrypoint: > br i1 %arg3, label %L0, label %L1 > > L0: ; preds = > %entrypoint > %0 = add nsw i64 %arg0, %arg4 > %1 = add nsw i64 %arg1, %arg4 > br label %L2 > > L1: ; preds = > %entrypoint > br label %L2 > > L2: ; preds =...

Hi, On Fri, Dec 30, 2011 at 3:09 AM, Tobias Grosser <tobias at grosser.es> wrote: > As it seems my intuition is wrong, I am very eager to see and understand > an example where a search limit of 4000 is really needed. > To make the ball roll again, I attached a testcase that can be tuned to understand the impact on compile time for different sizes of a basic block. One can also

On 12/29/2011 06:32 PM, Hal Finkel wrote: > On Thu, 2011-12-29 at 15:00 +0100, Tobias Grosser wrote: >> On 12/14/2011 01:25 AM, Hal Finkel wrote: >> One thing that I would still like to have is a test case where >> bb-vectorize-search-limit is needed to avoid exponential compile time >> growth and another test case that is not optimized, if >>

...; preds = %for.body, %entry %indvars.iv21247 = phi i64 [ 0, %entry ], [ %indvars.iv.next21248, %for.body ] %arrayidx = getelementptr inbounds [100 x i32]* %A, i64 0, i64 %indvars.iv21247 %0 = trunc i64 %indvars.iv21247 to i32 store i32 %0, i32* %arrayidx, align 4, !tbaa !0 %1 = add nsw i64 %indvars.iv21247, 42 %arrayidx2 = getelementptr inbounds [100 x i32]* %B, i64 0, i64 %indvars.iv21247 %2 = trunc i64 %1 to i32 store i32 %2, i32* %arrayidx2, align 4, !tbaa !0 %3 = shl nsw i64 %indvars.iv21247, 1 %arrayidx4 = getelementptr inbounds [100 x i32]* %C, i64 0, i64 %indvars...

*** Summary I'd like to propose (and implement) functionality in LLVM to determine when a poison value from an instruction is guaranteed to produce undefined behavior. I want to use that to improve handling of nsw, inbounds etc. flags in scalar evolution and LSR. I imagine that there would be other uses for it. I'd like feedback on this idea before I proceed with it. *** Details Poison values do produce undefined behavior if the poison becomes externally observable. A load or store to a poison address...

I'm trying to figure out about factors, however the on-line documentation is rather sparse. I guess, factors are intended for grouping arrays members into categories, which R names "Levels". And so we have: * state <- c("tas", "sa", "qld", "nsw", "nsw", "nt", "wa", "wa", "qld", "vic", "nsw", "vic", "qld", "qld", "sa", "tas", "sa", "nt", "wa", &q...

Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. Sure, we could drop nsw when moving these instructions, but there are still many other problems left. Please read more about the topic here: https://blog.regehr.org/archives/1496 For example, doing loop unswitching, followed b...

On 10/03/2013 01:22 AM, Andrew Trick wrote: > > I’m not sure how to make sense of an NUW flag coming from a sub. > > NSW is just a misnomer for signed overflow. SCEV canonicalizes sub a,b to add a, (-b). Unfortunately, signed overflow is not the same thing for sub and add... > > sub nsw %a, %b != add nsw %a, (-1 * %b) > > sub nsw i32, -1, INT_MIN is true. > > add nsw i32, -1, (-1 * INT_MIN) is fa...

John, Sanjoy, Nuno, David, Thanks for the tip, below are the relevant posts from the archives. I am suggesting something similar to Dan's third option below (Tue Nov 29 2011 "the nsw story”, Dan Gohman), when hoisting an instruction with ‘nsw’ it looses the ‘nsw’ attribute, but without saying “add-nsw is a fully side-effecting instruction”. This option was back then seen by Dan as too much effort, but the current proposal requires at least the same amount of effort. To be spec...

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 exampl...

...for a while that has finally reached a point where I can claim it to be "potentially viable". I'd like to gather some input from the community before moving too far ahead. # The problem There is a representation issue within SCEV that prevents it from fully using information from nsw/nuw flags present in the IR. This isn't just a theoretical issue, e.g. today LLVM won't unroll this loop: void f(int x, long* arr) { for (int i = x + 1; i < x + 3; i++) arr[i] = 40; } since SCEV is unable to exploit the no-overflow on x+1 and x+3 to prove that the loop only runs...

...; preds = %entry, %while.body %i.010 = phi i32 [ 0, %entry ], [ %inc, %while.body ] %arrayidx = getelementptr inbounds [10 x i32], [10 x i32]* @buffer, i32 0, i32 %i.010 %0 = load i32, i32* %arrayidx, align 4, !tbaa !2 %cmp1 = icmp ne i32 %0, -559038737 %inc = add nuw nsw i32 %i.010, 1 %cmp11 = icmp eq i32 %i.010, 0 %cmp = or i1 %cmp11, %cmp1 br i1 %cmp, label %while.body, label %while.end while.end: ; preds = %while.body %arrayidx2 = getelementptr inbounds [10 x i32], [10 x i32]* @buffer, i32 0, i32 %i.010 %1 = load...

...ed with SCEV) define void @func([132 x [140 x float]]* nocapture dereferenceable(73920)) local_unnamed_addr #0 { br label %2 ; <label>:2: ; preds = %11, %1 ; loop<%2> at depth 1 with exact backedge-taken count of 131 ; %12 = {1,+,1}<nuw><nsw><%2> ; %3 = {0,+,1}<nuw><nsw><%2> %3 = phi i64 [ 0, %1 ], [ %12, %11 ] br label %4 ; <label>:4: ; preds = %4, %2 ; loop<%4> at depth 2 with exact backedge-taken count of 139 ; %5 = {0,+,1}<nuw><nsw><%4&g...

...rke Roune <broune at google.com> wrote: > > > > *** Summary > > I'd like to propose (and implement) functionality in LLVM to determine > when a poison value from an instruction is guaranteed to produce undefined > behavior. I want to use that to improve handling of nsw, inbounds etc. > flags in scalar evolution and LSR. I imagine that there would be other uses > for it. I'd like feedback on this idea before I proceed with it. > > > > > > *** Details > > Poison values do produce undefined behavior if the poison becomes > extern...

I'm not sure I understand the poison/undef/UB distinctions. But on this example: define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { > entry: > %adds = add nsw i32 %x, %y > %addu = add nuw i32 %x, %y > %cond = select i1 %b, i32 %adds, i32 %addu > ret i32 %cond > } It is important to not propagate the nsw/nuw between the two SCEV expressions (which unification would do today, can I consider that a bug or is it a feature?). So we work-ar...

...i <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. > > But on this example: > > define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { >> entry: >> %adds = add nsw i32 %x, %y >> %addu = add nuw i32 %x, %y >> %cond = select i1 %b, i32 %adds, i32 %addu >> ret i32 %cond >> } > > > It is important to not propagate the nsw/nuw between the two SCEV > expressions (which unification would do today, can I consider that a bug o...

Is that why we do not deduce +<nsw> from "add nsw" either? Is that an intrinsic limitation of creating a context-invariant expressions from a Value* or is that a limitation of our implementation (our unification not considering the nsw flags)? On Wed, Aug 15, 2018 at 12:39 PM Friedman, Eli <efriedma at codeaurora.o...