basic-constructs/functions.rst: fix function type and getelementptr i…

[thautwarm]

basic-constructs/functions.rst: fix function type and getelementptr instructions.
My environment information:

• LLVM: 6.0.0
• OS: x86_64-Ubuntu-16.04-xenial'

Maybe some problems are caused by the version.

The problems lie in this snippet:

 %1 = call i32 (i8*, ...)* @printf(i8* getelementptr([20 x i8]* @.text, i32 0, i32 0), i32 %argc)

And the problems are:

1. @.text has been already used when compiling. I cannot define a variable named @.text or I'll get an ERROR LLVM ERROR: symbol '.text' is already defined. I don't know why but I think we'd better do some name mangling.
   I change the name from @.text to @.textstr...

2. The call instruction is followed by type of the function, it should be value type not a pointer type.

 call i32 (i8*, ...)* @printf` -> `call i32 (i8*, ...) @printf

3. At getelementptr instruction, the first argument is missing. getelementptr([20 x i8]* @.textstr, i32 0, i32 0) -> getelementptr([20 x i8], [20 x i8]* @.textstr, i32 0, i32 0)

[thautwarm]

Hey, dear Michael, I doubt there might be endless problems in coming days...
If so, I'll review the codes for you and make a big PR at the end.

This repo is nice! It's amazingly human-friendly with a good structure, thanks a lot!

[f0rki]

Thanks a lot!

The original version of the document (which was written by @archfrog) is quite old. I'm not sure what LLVM version he used. I haven't gotten around to update all the LLVM listings to the recent syntax changes.

I'm very thankful for any contribution in this regard!

[thautwarm]

It's my pleasure to contribute here! I do have learned a lot about LLVM details these days.

I wonder that if I could explicitly note the LLVM version above each LLVM IR example after testing it?
This could be some tedious but we can make this plan and keep doing this regularly...

[archfrog]

I don't recall the exact version of LLVM that I used, but it goes back some 6 years or so, so it was probably in the 2.x series. No doubt, a lot has changed since then.

I like the idea of noting the version used. I should have done that, but never thought of it because I thought I'd be working on the document on a permanent basis.

Thanks for your contribution! :-)

[archfrog]

Oh, I forgot to say that I intentionally left out name mangling so as to keep things simple. I think it would be good with a chapter on how to mangle names, though. After all, a mangled name is little more than a serialized data type with some additional info such as identifier name and so on.

[thautwarm]

@archfrog
Hello, the LLVM expert!
I think the idea of keeping things simple makes sense in some degree, but it could be better if the related conventions are listed in some GUIDELINE chapter. It's a bit confusing at the first for the code cannot run directly.
And a rational standard(or some good routines) for name mangling could help a lot but I don't have a systematic knowledge of it. Looking forward to your sharing if you have spare time! :-)

[archfrog]

Haha, I'm not an LLVM expert :-) I started the document to help newbies like myself and others trying to learn the basics of how to use LLVM for real production code.

Yes, the code should be made runnable again. I believe I did test almost all snippets with the version of LLVM that I was using, but, alas, that's quite a while back.

I'll see if I can contribute my knowledge of name mangling somehow.

[thautwarm]

Thanks again for this pretty document.
Don't worry about the reproducibility of examples or creating new commits, take your time, we can make it together :-)

[f0rki]

there is a bit of name mangling already there:
http://mapping-high-level-constructs-to-llvm-ir.readthedocs.io/en/latest/basic-constructs/functions.html#function-overloading

I think the updated GEP instruction syntax are the biggest problem in terms of runnability (see #17).

I already dumped all the inline LLVM IR snippets also to files, so in theory we could just check whether those are all runnable/compilable.