search for: addnsw

...i1 = sle 192:i8, %0 result %4 %0:i32 = var %1:i32 = shlnsw %0, 1:i32 %2:i32 = or 1:i32, %1 %3:i1 = slt %1, %2 infer %3 result 1:i1 "or" and "and" are basically interchangeable as far as cost is concerned, so this one also seems like a "subset": %0:i32 = var %1:i32 = addnsw 4294967295:i32, %0 %2:i32 = var %3:i32 = or 1:i32, %2 %4:i32 = addnsw %1, %3 infer %4 %5:i32 = and 4294967294:i32, %2 %6:i32 = add %0, %5 result %6 -- Sean Silva > > Thanks, > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists...

> Interesting. Do you happen to have some examples laying around? Sorry, no, I'll have to re-run. I felt that the select-heavy results were sort of humorous and clever at first, but then just annoying. > Except for decode-limited situations, in general decreasing the critical path length is more important > than eliminating instructions. The critical path length is a

...not-allowed to happen because of SCEV expressions can represent instructions in different contexts (e.g. in different execution paths). In the IR these flags mean poison. This is a semantical mismatch that gives a big proof burden on SCEV. To give an example (test/Analysis/ScalarEvolution/nsw.ll - addnsw): 01: entry: 02: %tmp = add i32 %a, %b 03: %cmp = icmp sgt i32 %tmp, 0 04: br i1 %cmp, label %greater, label %exit 05: greater: 06: %tmp2 = add nsw i32 %a, %b 07: br label %exit 08: exit: 09: %result = phi i32 [ %a, %entry ], [ %tmp2, %greater ] 10: ret i32 %result In the following exampl...

Hi all, This is about a project I've been prototyping on-and-off 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