On Thu, Mar 02, 2017 at 06:18:43PM +0100, Luc Van Oostenryck 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?
>
> 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.
OK, I've just checked and indeed removing this assignment to ->priv
in output_op_store() was wrong and is most probably very related to
your problem. I used something as simple as:
void foo(int *p, int a, int b)
{
int c = a + b;
p[0] = c;
p[1] = c;
}
Which returned:
Stored value type does not match pointer operand type!
store void <badref>, i32* %8
And with this assignment removed this error is no more and the
generated LLVM IR is:
define void @foo(i32*, i32, i32) {
%R3 = add i32 %1, %2
%3 = bitcast i32* %0 to i8*
%4 = getelementptr inbounds i8, i8* %3, i64 0
%5 = bitcast i8* %4 to i32*
store i32 %R3, i32* %5
%6 = bitcast i32* %0 to i8*
%7 = getelementptr inbounds i8, i8* %6, i64 4
%8 = bitcast i8* %7 to i32*
store i32 %R3, i32* %8
ret void
}
And the generated x86 code is:
addl %edx, %esi
movl %esi, (%rdi)
movl %esi, 0x4(%rdi)
retq
Luc Van Oostenryck
--
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
