Re: Sparse-LLVM issue compiling NULL pointers

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

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