search for: psub

...es to a pointer came from inttoptr is assumed to possibly access anywhere, therefore it may block store-to-load forwarding, merging two same loads, etc. I believe this can be addressed by applying two patches - first one is representing pointer subtraction with a dedicated intrinsic function, llvm.psub, and second one is disabling InstCombine transformation %q = load i8*, i8** %p1 store i8* %q, i8** %p2 => %1 = bitcast i8** %p1 to i64* %q1 = load i64, i64* %1, align 8 %2 = bitcast i8** %p2 to i64* store i64 %q1, i64* %2, align 8 This transformation can introduce inttoptrs lat...

Hello Sanjoy, Yep, combining it with propagateEquality of pointers may raise problem. :\ However I believe propagateEquality should be fixed properly, and adding psub also suggests a solution for that. :) It is sound to replace a pointer with another if subtraction of them is 0: a = malloc() free(a) b = malloc() // Assume b == a numerically if ((psub inbounds a b) == 0) { // a and b are pointing to different objects, so the comparison becomes poison use(a) }...

...; to possibly access anywhere, therefore it may block >> store-to-load forwarding, merging two same loads, etc. >> >> I believe this can be addressed by applying two patches - first one is >> representing pointer subtraction with a dedicated intrinsic function, >> llvm.psub, and second one is disabling InstCombine transformation >> >> %q = load i8*, i8** %p1 >> store i8* %q, i8** %p2 >> => >> %1 = bitcast i8** %p1 to i64* >> %q1 = load i64, i64* %1, align 8 >> %2 = bitcast i8** %p2 to i64* >> store i64...

...cally, if one of `A` or `B` is escaped/captured, the > subtraction can be used to escape or capture the other pointer. So *some* of the conservative treatment is necessary. What is the plan to update all the analyses to remain correct? What > correctness testing have you done? Correctness of psub is guaranteed by the specification of pointer subtraction of C/C++. When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object (6.5.6.9). So, if the two pointers p and q point to different objects, we can define llvm.psu...

...you wrote, I believe we can use 'sub(ptrtoint p, ptrtoint q)' as before. This addresses concerns regarding correctness of existing pointer analysis. So you don't lose expressiveness, while you gain precision when possible. A concrete suggestion is to add a parameter like 'bool use_psub' to IRBuilder::CreatePtrDiff. When Clang inserts a pointer subtraction, use_psub is set to true. When LLVM inserts it, it is set as false. Default value of use_psub is false, so existing LLVM passes will still insert sub (ptrtoint, ptrtoint) but most of ptrtoints are inserted from Clang, so #...

...it may block >>>> store-to-load forwarding, merging two same loads, etc. >>>> >>>> I believe this can be addressed by applying two patches - first one is >>>> representing pointer subtraction with a dedicated intrinsic function, >>>> llvm.psub, and second one is disabling InstCombine transformation >>>> >>>> %q = load i8*, i8** %p1 >>>> store i8* %q, i8** %p2 >>>> => >>>> %1 = bitcast i8** %p1 to i64* >>>> %q1 = load i64, i64* %1, align 8 >>>&...

..., "...", x) - ## escape any odd \, e.g. \n - x <- fsub("\\\\", BSL, x) # change even ones x <- fsub("\\", BSL2, x) # odd ones - x <- fsub(BSL, "\\\\", x) # change back x <- psub("(?<!\\\\)\\{", "\\\\{", x) x <- psub("(?<!\\\\)}", "\\\\}", x) x <- fsub(BSL2, "\\bsl{}", x)library(tools)

...is similar to one adopting optimizations/analyses that exploit signed overflow / TBAA / etc. Juneyoung Lee On Tue, Jan 15, 2019 at 11:59 AM David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 14/01/2019 20:55, Juneyoung Lee via llvm-dev wrote: > > Correctness of psub is guaranteed by the specification of pointer > > subtraction of C/C++. > > When two pointers are subtracted, both shall point to elements of the > > same array object, or one past the last element of the array object > > (6.5.6.9). > > As with many things in the C and...

...inop-widen2.ll >> llvm/trunk/test/CodeGen/X86/vec_shuffle-27.ll >> llvm/trunk/test/CodeGen/X86/vec_shuffle-39.ll >> llvm/trunk/test/CodeGen/X86/widen_cast-1.ll >> llvm/trunk/test/CodeGen/X86/win64_alloca_dynalloca.ll >> llvm/trunk/test/CodeGen/X86/x86-64-psub.ll >> llvm/trunk/test/CodeGen/X86/x86-shifts.ll >> llvm/trunk/test/CodeGen/X86/zext-fold.ll >> llvm/trunk/test/CodeGen/X86/zext-sext.ll >> llvm/trunk/test/DebugInfo/X86/dbg-value-dag-combine.ll >> >> Modified: llvm/trunk/lib/Target/X86/X86Subtarget.h...

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

...proofcheck.ll 122 207733 8 0.02 206375 0 0.03 207716 PropIDUtils.ll 2 65132 0 0.01 65097 0 0.01 65097 PropVariantConversions.ll 4 45669 0 0.01 45641 0 0.01 45641 PropVariant.ll 23 90547 2 0.01 84417 2 0.01 82355 pseudo.ll 11 132106 0 0.02 132076 0 0.01 132076 psqrt.ll 1 7056 0 0.01 7029 0 0.00 7029 psub.ll 1 20187 0 0.00 20160 0 0.01 20160 psymodel.ll 2 270891 0 0.03 270860 0 0.03 270860 ptalloc.ll 3 6768 0 0.01 6734 0 0.01 6734 ptoa.ll 1 16862 0 0.01 16835 0 0.01 16835 ptou.ll 1 7432 0 0.01 7405 0 0.01 7405 puzzle.ll 7 13008 0 0.01 12984 0 0.01 12984 Puzzle.ll 8 59672 0 0.01 59653 0 0.01 59653 pw...