On Thu, Mar 02, 2017 at 04:30:53PM +0000, Dibyendu Majumdar wrote: > >> 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. Good. > >> 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. That's obviously wrong. > >> %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. OK. > >> 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? No, no. What is stored in ->priv is the target's LLVMValueRef (and for a store the 'target' is what need to be stored). And indeed there is a bug there: it's target_in that should be stored in ->priv (in fact, for a store, there is no need to put anything at all in this field; at least I don't see any reason why it should). Nice catch. I don't know how it's related to your problem though. 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
