[LLVMdev] ParseAssemblyString does not resolve existing type names

[Jan Rehders]

Hi,

I'm having some issues using ParseAssemblyString on code that
references types added to the module before. What I'm doing is: create
a new LLVM module, create a few named struct types and functions in
it, and then use ParseAssemblyString to load new code into this.
Whenever this new code references the types created before I'm seeing
confusing behaviour. Instead of using the existing type foo_t the
parser seems to create a new opaque struct type foo_t.0 and uses that
instead of foo_t. This looks like the same behaviour as when creating
a new struct type with a name that is already used.

The following small program reproduces the problem:
https://gist.github.com/sheijk/b605641cd9744b4bc2ab

Compile and run like this (using Mac OS X 10.9): "make llvm-test && ./llvm-test"
to see what happens when the type is part of the parsed source use
"./llvm-test --combined"

The output I'm getting is this:
> ---- Module after type:
> ; ModuleID = 'test'
>
> %struct.foo_t = type { i32 }
>
> declare void @dummy(%struct.foo_t)
>
> ---- module end
> <string>:1:19: LLVM error: use of undefined type named 'struct.foo_t'
> ---- Module after func:
> ; ModuleID = 'test'
>
> %struct.foo_t = type { i32 }
> %struct.foo_t.0 = type opaque
>
> declare void @dummy(%struct.foo_t)
>
> declare void @func(%struct.foo_t.0*)
>
> ---- module end

I'm not sure whether I'm doing something wrong here. I ran into this
when porting my project from LLVM 2.9 to 3.5. In LLVM 2.9 this used to
work and I could imagine this behaviour changed with the type system
refactoring in 3.0 but I'm not sure the behaviour I'm seeing is
intended.

The parser in lib/AsmParser/LLParser.cpp seems to look up named
structs in it's member NamedStructs in function ParseType.
NamedStructs gets polulated when new types get defined in
ParseNamedType but I don't see it getting filled with the existing
types of the module. So ParseType will create a new opaque type that
gets renamed due to the naming conflict. Think could easily be solved
by looking up the named type in the module (LLParser::M) inside
ParseType.

So should I just proceed and write a small patch for this or is there
some better way I should do what I do? Unfortunately I will have to
keep parsing .ll files for now.

Cheers,
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-parse.cpp
Type: text/x-c++src
Size: 3743 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/a2c7d284/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-parse.mk
Type: application/octet-stream
Size: 342 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/a2c7d284/attachment.obj>