search for: int2ptr

...ex 19cabb6..a665051 100644 --- a/generator/perl.ml +++ b/generator/perl.ml @@ -242,7 +242,7 @@ DESTROY (sv) HV *hv = (HV *) SvRV (sv); SV **svp = hv_fetch (hv, \"_g\", 2, 0); if (svp != NULL) { - guestfs_h *g = (guestfs_h *) SvIV (*svp); + guestfs_h *g = INT2PTR (guestfs_h *, SvIV (*svp)); _close_handle (g); } diff --git a/perl/typemap b/perl/typemap index 508e378..0a92e53 100644 --- a/perl/typemap +++ b/perl/typemap @@ -14,7 +14,7 @@ O_OBJECT_guestfs_h SV **svp = hv_fetch (hv, \"_g\", 2, 0); if (svp == NULL)...

My general feeling is this: No optimizations should be creating int2ptr/ptr2int. We really need to fix them all. They should use pointer casts and i8* GEPs. This has, unfortunately, been a problem for a long time. As Johannes says, optimizing int2ptr/ptr2int is very tricky. In part, becaue all dependencies, including implicit control dependencies, end up being part...

Hi all, We noticed a lot of unnecessary ptrtoint instructions that stand in way of some of our optimizations; the code pattern looks like this: bb1: %int1 = ptrtoint %struct.s* %ptr1 to i64 bb2: %int2 = ptrtoint %struct.s* %ptr2 to i64 %bb3: %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] %ptr = inttoptr i64 %phi.node to %struct.s* In short, the pattern above arises due to: 1.

Hi Bruce, On 25.02.19 13:10, Bruce Hoult wrote: > LLVM has no idea whether the address computed by GEP is actually > within a legal object. The "inbounds" keyword is just you, the > programmer, promising LLVM that you know it's ok and that you don't > care what happens if it is actually out of bounds. > >

...g LLVM syntax, I usually deal with this in terms of C or Rust syntax): Can %G in the following programs be poison? If yes, what is the analysis that would be weakened or the optimization that could no longer happen if "GEPi %P 0" was instead defined to always return %P? # example1 %P = int2ptr 4 %G = gep inbounds %P 0 # example2 %P = call noalias i8* @malloc(i64 12) call void @free(i8* %P) %G = gep inbounds %P 0 The first happens in Rust all the time, and we rely on not getting poison. The second doesn't occur in Rust (to my knowledge), but it seems somewhat inconsistent to retur...

.... That nicely accommodates all uses of getelementptr that just compute addresses without ever using them for a memory access (using them only, e.g. to compute offsets or compare pointers). But this is not how the LLVM LangRef is written, unfortunately. >> # example1 >> >> %P1 = int2ptr 4 >> %G1 = gep inbounds %P1 0 >> >> # example2 >> >> %P2 = call noalias i8* @malloc(i64 12) >> call void @free(i8* %P2) >> %G2 = gep inbounds %P2 0 >> >> The first happens in Rust all the time, and we rely on not getting >> poison. The se...

Hi, I try to understand why llvm can't optimize this small piece of code. My expectation is that the IR will be optimized to a " ret i64 2101545. But somehow the alias analysis fails when the pointer is casted to an integer value, so the dead code eliminator can't optimize it away. Could someone explain to me why this is failing and if there is a solution for that ? I can trick the

On Dec 6, 2011, at 3:29 PM, Peter Cooper wrote: > The best case i can think of is embedded developers needing to layout functions or globals in memory. > Currently they would have to resort to a linker script or assembly hacks for this. This proposal also requires extending object file formats and linkers, and this impacts a lot of people, so it would want a pretty compelling

...;>> A side-effect based on the GEP will however __locally__ introduce an >>>>> dereferencability assumption (in my opinion at least). Let's say the >>>>> code looks like this: >>>>> >>>>> >>>>> %G = gep inbounds (int2ptr 4) 0 ; We don't know anything about the >>>>> dereferencability of ; the memory at address 4 here. br %cnd, >>>>> %BB0, %BB1 >>>>> >>>>> BB0: ; We don't know anything about the dereferencability of ; the >>>>> m...