On 2 March 2017 at 16:29, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > Hi Luc, > > On 2 March 2017 at 16:04, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: >> On Thu, Mar 02, 2017 at 02:33:09PM +0000, Dibyendu Majumdar wrote: >>> This occurs in calc_memop_addr() function when it tries to do following: >>> >>> as = LLVMGetPointerAddressSpace(LLVMTypeOf(src)); >>> >>> If I dump insn, insn->src, and the LLVM value and type before this line, I get: >>> >>> 1) insn load.64 %r18 <- 8[%r2] >>> 2) pseudo %r2 >>> 3) store %struct.buffer_type_st* %R2, %struct.buffer_type_st** %26 >>> 4) void >>> >>> The type of the LLVM store instruction is 'void'. >>> >>> My guess is that something is going horribly wrong in the way member >>> access is handled. >>> >>> If you are able to reproduce this and have any suggestions then please >>> let me know. >> >> Why I try your code (without LLVM assertions), I got indeed several >> problems: >> Call parameter type does not match function signature! >> i0 16 >> i64 %1 = call i8* @malloc(i0 16) > > I have the function argument fix so I don't get the malloc error. > >> Invalid bitcast >> %27 = bitcast void <badref> to i8** >> Both operands to a binary operator are not of the same type! > > I think this corresponds to the code that fails - the type of the LLVM > instruction is 'void' and the code is trying to cast to it or > something. > >> %R31 = add void <badref>, i64 %R30 >> Stored value type does not match pointer operand type! >> store void %R31, i8** %46 >> > > The code aborts at previous step > >> The first one is really weird but I think you don't see it. > > It is the function call issue, for which I have a fix I described. > >> The next two I have no idea. >> The fourth have something obviously wrong with the type of its 'target'. > >> However, while running sparse-llvm on some code sample I use to test >> the linearization, I see that most errors are type errors and are >> related to pointer arithmetic, exactly where LLVM's getelemptr is used. >> Most offending instructions are OP_ADD (but since I have tests for >> bitfields I see also errors for OP_AND, OP_OR & OP_LSR). >> I guess that if you test OP_ADD instruction with pointer on one side >> and integer on tne other side and issue an appropriate LLVMBuildGEP(), >> things will already be much better. >> > > 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] > store.64 %r2 -> 0[%arg1] > load.64 %r18 <- 8[%r2] > store.64 %r18 -> 16[%arg1] > load.64 %r23 <- 32[%arg1] > load.64 %r25 <- 40[%arg1] > mulu.64 %r26 <- %r23, %r25 > add.64 %r27 <- %r18, %r26 > store.64 %r27 -> 24[%arg1] > ret Just to clarify I mean above that the way Sparse-LLVM handles it is broken. -- 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
