<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 6:28 PM, Robin Eklind <span dir="ltr"><<a href="mailto:carl.eklind@myport.ac.uk" target="_blank">carl.eklind@myport.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello Sean,<br>
<br>
Thank you for your reply. I'll give your suggestion to item 6 and 7 a try tonight. I'll start a compilation and let it run throughout the night. My laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time :)<br></blockquote><div><br></div><div>This is why I did so much documentation work when in college. The docs build much faster.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Regarding item 8. I don't know if anyone is using "": in the wild so fixing the implementation might make sense. If not the documentation (e.g. the QuoteLabel comment) should be updated to be in line with the implementation.<br></blockquote><div><br></div><div>FYI the textual IR doesn't have a compatibility guarantee (we try not to egregiously change it, but users don't expect .ll to work across versions). </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I only included item 9 since I stumbled upon it once cross-referencing the source code with the language specification. Bitrot for a project of this size is to be expected.<br>
<br>
I'm still very interested to hear about the items related to types, e.g. item 1 and 2. Is there a good reference which describes how type equality works in LLVM IR? If the source code is the reference, could someone with the high level knowledge get me up to speed?<br></blockquote><div><br></div><div>Off the top of my head maybe <a href="http://blog.llvm.org/2011/11/llvm-30-type-system-rewrite.html">http://blog.llvm.org/2011/11/llvm-30-type-system-rewrite.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Item 1 still confuses me, so I'd be very happy if someone with more insight could clarify if this is the intended behaviour and if so the motivation behind it.<br>
<br>
As it so happens, I forgot to include item 10 :)<br>
<br>
* Item 10 - lli vs. clang output<br>
<br>
Using the same source files as before, it seems like lli and clang treats common linkage and constant variables differently. The following execution demonstrates the return value after executing i.ll, j.ll, k.ll and l.ll with lli and clang respectively:<br>
<br>
> $ clang i.ll && ./a.out ; echo $?<br>
> 37<br>
><br>
> $ lli i.ll ; echo $?<br>
> 37<br>
><br>
><br>
> $ clang j.ll && ./a.out ; echo $?<br>
> 0<br>
><br>
> $ lli j.ll ; echo $?<br>
> 42<br>
><br>
><br>
> $ clang k.ll && ./a.out ; echo $?<br>
> 37<br>
><br>
> $ lli k.ll ; echo $?<br>
> 37<br>
><br>
><br>
> $ clang l.ll && ./a.out ; echo $?<br>
> Segmentation fault<br>
> 139<br>
><br>
> $ lli l.ll ; echo $?<br>
> 37<br></blockquote><div><br></div><div>Some of these linkage combinations and operations have dubious semantics. Talking briefly with Rafael Espindola over a build, sounds like we should mostly tighten up the verifier to remove some of these weird cases. For example, storing to a constant is sort of .... I'm sort of surprised it works at all.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Looking forward to hear more about type equality, or get a pointer as to where I can read up about it.<br>
<br>
Cheers /Robin Eklind<div class=""><div class="h5"><br>
<br>
<br>
On 01/28/2015 03:45 PM, Sean Silva wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A couple quick comments inline (didn't touch on all points):<br>
<br>
On Wed, Jan 28, 2015 at 1:49 AM, Robin Eklind <<a href="mailto:carl.eklind@myport.ac.uk" target="_blank">carl.eklind@myport.ac.uk</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello everyone!<br>
<br>
I've recently had a chance to familiarize myself with the nitty-gritty<br>
details of LLVM IR. It has been a great learning experience, sometimes<br>
frustrating or confusing but mostly rewarding.<br>
<br>
There are a few cases I've come across which seems odd to me. I've tried<br>
to cross reference with the language specification and the source code to<br>
the best of my abilities, but would like to reach out to an experienced<br>
crowd with a few questions.<br>
<br>
Could you help me out by taking a look at these examples? To my novice<br>
eyes they seem to highlight inconsistencies in LLVM IR (or the reference<br>
implementation), but it is quite likely that I've overlooked something.<br>
Please help me out.<br>
<br>
Note: the example source files have been attached and a copy is made<br>
available at <a href="https://github.com/mewplay/ll" target="_blank">https://github.com/mewplay/ll</a><br>
<br>
* Item 1 - named pointer types<br>
<br>
It is possible to create a named array pointer type (and many others), but<br>
not a named structure pointer type. E.g.<br>
<br>
%x = type [1 x i32]* ; valid.<br>
%x = type {i32}* ; invalid.<br>
<br>
Is this the intended behaviour? Attaching a.ll, b.ll, c.ll and d.ll for<br>
reference. All files except d.ll compiles without error using clang version<br>
3.5.1 (tags/RELEASE_351/final).<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
$ clang d.ll<br>
d.ll:3:16: error: expected top-level entity<br>
%x = type {i32}*<br>
^<br>
1 error generated.<br>
</blockquote>
<br>
Does it have anything to do with type equality? (just a hunch)<br>
<br>
* Item 2 - equality of named types<br>
<br>
A named integer type is equivalent to its literal type counterpart, but<br>
the same is not true for named and literal structures. I am certain that<br>
I've read about this before, but can't seem to locate the right section of<br>
the language specification; could anyone point me in the right direction?<br>
Also, what is the motivation behind this decision? I've skimmed over the<br>
code which handles named structure types (in lib/IR/core.cpp), but would<br>
love to hear the high level idea.<br>
<br>
Attaching e.ll, f.ll, g.ll and h.ll for reference. All compile just file<br>
except h.ll, which produces the following error message (using the same<br>
version of clang as above):<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
$ clang h.ll<br>
h.ll:10:23: error: argument is not of expected type '%x = type { i32 }'<br>
call void (%x)* @foo({i32} {i32 0})<br>
^<br>
1 error generated.<br>
</blockquote>
<br>
* Item 3 - zero initialized common linkage variables<br>
<br>
According to the language specification common linkage variables are<br>
required to have a zero initializer [1]. If so, why are they also required<br>
to provide an initial value?<br>
<br>
Attaching i.ll and j.ll for reference. Both compiles just fine and once<br>
executed i.ll returns 37 and j.ll return 0. If the common linkage variable<br>
@x was not initialized to 0, j.ll would have returned 42.<br>
<br>
* Item 4 - constant common linkage variables<br>
<br>
The language specification states that common linkage variables may not be<br>
marked as constant [1]. The parser doesn't seem to enforce this<br>
restriction. Would doing so cause any problems?<br>
<br>
Attaching k.ll and l.ll for reference. Both compiles just fine, but once<br>
executed k.ll returns 37 (e.g. the constant variable was overwritten) while<br>
l.ll segfaults as expected when it tries to overwrite a read-only memory<br>
location.<br>
<br>
* Item 5 - appending linkage restrictions<br>
<br>
An extract from the language specification [1]:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
"appending" linkage may only be applied to global variables of pointer<br>
</blockquote>
to array type.<br>
<br>
Similarly to item 4 this restriction isn't enforced by the parser. Would<br>
it make sense doing so, or is there any problem with such an approach?<br>
<br>
* Item 6 - hash token<br>
<br>
The hash token (#) is defined in lib/AsmParser/LLToken.h (release version<br>
3.5.0 of the LLVM source code) but doesn't seem to be used anywhere else in<br>
the source tree. Is this token a historical artefact or does it serve a<br>
purpose?<br>
<br>
</blockquote>
<br>
Try deleting it. If the tests pass send a patch. Same for item 7.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
* Item 7 - backslash token<br>
<br>
Similarly to item 7 the backslash token doesn't seem to serve a purpose<br>
(with regards to release version 3.5.0 of the LLVM source code). Is it used<br>
somewhere?<br>
<br>
* Item 8 - quoted labels<br>
<br>
A comment in lib/AsmParser/LLLexer.cpp (once again, release version 3.5.0<br>
of the LLVM source code) describes quoted labels using the following regexp<br>
(e.g. at least one character between the double quotes):<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
/// QuoteLabel "[^"]+":<br>
</blockquote>
<br>
In contrast the reference implementation accepts quoted labels with zero<br>
or more characters between the double quotes. Which is to be trusted? The<br>
comment makes more sense as the variable name would effectively be blank<br>
otherwise.<br>
<br>
</blockquote>
<br>
Looks an empty name just results in the thing becoming unnamed. That's sort<br>
of confusing, but probably not harmful. Maybe we use an empty name as a<br>
sentinel for "unnamed", so it sort of just was an accident of the<br>
implementation.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
* Item 9 - undocumented calling conventions<br>
<br>
The following calling conventions are valid tokens but not described in<br>
the language references as of revision 223189:<br>
<br>
intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc,<br>
kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc,<br>
msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func,<br>
x86_64_sysvcc, x86_64_win64cc, kw_ghccc<br>
<br>
<br>
</blockquote>
This is just bitrot.<br>
<br>
-- Sean Silva<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
Lastly I'd just like to thank the LLVM developers for all the time and<br>
hard work they've put into this project. I'd especially like to thank you<br>
for providing a language specification along side of the reference<br>
implementation! Keeping it up to date is a huge task, but also hugely<br>
important. Thank you!<br>
<br>
Kind regards<br>
/Robin Eklind<br>
<br>
[1]: <a href="http://llvm.org/docs/LangRef.html#linkage-types" target="_blank">http://llvm.org/docs/LangRef.<u></u>html#linkage-types</a><br>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>