Re: Sparse-LLVM issue compiling NULL pointers

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

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