On Thu, Mar 02, 2017 at 05:03:06PM +0000, Dibyendu Majumdar wrote: > On 2 March 2017 at 16:29, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > > Here is the output from linearize. I think the way stores and loads > > are handled is broken. It appears that the last store / load > > instruction is stored in insn->target->priv, and then used later on > > ... I do not understand what the code is trying to do. Is it trying to > > optimize away stores and loads? > > > > grow_allocator: > > .L0000022DAFA94A88: > > <entry-point> > > call.64 %r1 <- malloc, $16 > > ptrcast.64 %r2 <- (64) %r1 > > load.64 %r4 <- 32[%arg1] > > load.64 %r6 <- 40[%arg1] > > mulu.64 %r7 <- %r4, %r6 > > call.64 %r8 <- malloc, %r7 > > ptrcast.64 %r9 <- (64) %r8 > > store.64 %r9 -> 8[%r2] > > load.64 %r12 <- 0[%arg1] > > store.64 %r12 -> 0[%r2] > > It appears that the sparse-llvm code is storing the LLVM instruction > for '%r2' in pseudo->priv. > > > store.64 %r2 -> 0[%arg1] Ah yes, it overwrite the correct value previously stored there (the LLVMValueRef corresponding to %r2) with the return value of LLVMBuildStore(). > And then it using the value of the store instruction whenever it sees '%r2'? > > > load.64 %r18 <- 8[%r2] > > But here it fails because it needs to cast the LLVM store instruction > to be a pointer to access 8[]? Yes, now anything using %r2 will go wrong. Removing the last line of output_op_store() (insn->target->priv = target;) should fix this. Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
