[LLVMdev] Need Help With Verifier

[Reid Spencer]

On Fri, 2003-11-21 at 10:05, Chris Lattner wrote:
> On Fri, 21 Nov 2003, Reid Spencer wrote:
> 
> > While it is great that LLVM has an IR Verifier, its a little troublesome
> > to use because it separates the point of detection from the source of
> > the problem. That is, the verifier gets run on a module or function
> > after its been built. By that point, the compiler's state has moved past
> 
> Well, you can run the verifier any time you want: there is a verifier
> pass, or you can manually call verifyModule/verifyFunction.  Aside from
> that, I'm not sure exactly what we could add...

I was thinking about a little more immediate verification, like when an
instruction gets added to a basic block or a basic block gets added to a
function. I understand that this could be tricky because of unresolved
references, etc. In any event, moving the detection of the problem
closer to the source of the problem would be a real win.  How, is the
question for which I don't have many ideas. *shrug*

> > Now, here's the specific problem. When the verifier runs, I get:
> >
> > Stored value is not of right type for indices!
> > void <badref>
> > type[1024 x int] [1024 x int]
> 
> WOW.  That is an absolutely horrible error message.  I've fixed both the
> error message itself (it should now read "Stored value type does not
> match pointer operand type!"), and the things being printed.  The first
> one is supposed to print the Store instruction itself (allowing you to
> actually find the thing), but didn't due to an unrelated change in the
> verifier recently. :(
> 
> Try it now.

Will do! Thanks!
 
> > So, for example, if I want to add two numbers stored in memory, I add
> > the two load instructions used to fetch the values. Right? Please say
> > yes or I have to change my whole conception of how this works! :)
> 
> yes!  :)

Phew!

> >     std::vector<Value*> indexVec;       // Index vector
> >     indexVec.push_back(loadop);         // Insert single index
> >     GetElementPtrInst* gep = new GetElementPtrInst(
> >         TheStack, indexVec );
> >     bb->getInstList().push_back( gep );         // Put GEP in Block
> 
> This is the problem.  The deal here is that the 'getelementptr'
> instruction actually takes one extra argument than you are giving it (this
> is, by far, the most confusing aspect of the getelementptr instruction).
> Lets say your stack is of type:
> 
> %Stack = ...  <[100 x int] *>
> 
> If you index into this with a single "long" index, you will get this:
> 
> %Ptr = getelementptr [100 x int]* %Stack, long %X     ; <[100 x int] *>
> 
> Where what you really want is this:
> 
> %Ptr = getelementptr [100 x int]* %Stack, long 0, long %X     ; <int*>
> 
> 
> The deal with the initial zero is that it is specifying how to index
> _through the pointer_, which is often forgotten about.  This allows LLVM
> to translate this C code:
> 
> int *P = ...
> P = P + 1;
> 
> into this LLVM code:
> 
> %P.1 = ...
> %P.2 = getelementptr int* %P.1, long 1

Aha! *light blub just went on*

> 
> This probably won't make sense the first time you see it.  Take a look at:
> http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr

Hey, I read that three times! I'm going to update it to more
specifically identify this "you gotta dereference the pointer first"
characteristic.

> And remember that we are turning the '->' syntactic sugar into it's
> equivalent [0] form.

Right .. good way to think about it.

> If you have any other questions about this, please just let me know (and
> try out the fixed verifier too :)
> 
> -Chris

You'll be the first to know :) .. and, I'm off to try the new verifier.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031121/d7a7bb60/attachment.sig>