[PATCH] D36712: Emit section information for extern variables

[Elizabeth Andrews via Phabricator via cfe-commits]

eandrews added inline comments.


================
Comment at: docs/LangRef.rst:629
+corresponding to the LLVM module, section information specified in the 
+declaration is retained in LLVM IR to enable OpenCL processes.
+
----------------
kparzysz wrote:
> sdardis wrote:
> > efriedma wrote:
> > > This doesn't really explain the part that matters. For LangRef, it doesn't matter how the frontend decides to generate declarations (and it might be different for frontends other than clang).  And OpenCL might motivate this, but it has nothing to do with the semantics.
> > > 
> > > The key question here is what it actually means.  Is it a promise the that a definition will exist for the given symbol in the given section?  If so, what happens if the symbol is actually in a different section?  ("Undefined behavior" is probably an acceptable answer, but it needs to be stated explicitly.)
> > > to enable OpenCL processes.
> > 
> > for targets which make use of this section information. 
> > 
> > I would also work in a sentence that says that attaching section information to a external declaration is an assertion or promise that the definition is located in that section. If the definition is actually located in a different section the behaviour is undefined.
> > 
> > I'm favouring "undefined behaviour" in the error case as behaviour is so target and environment specific.
> The other side of the problem is, what if the declarations don't have any section information, but the definition does? Is that also an undefined behavior? I'm in favor of considering it UB as well, but I'm not sure what impact it would have on currently valid IR.
The changes I made in Clang assume that the definition is located in the same section specified in the declaration. If its different, the IR for the translation unit with the extern declaration will emit whatever section was specified in the declaration while the variable is actually located elsewhere. I am not sure what the consequences of this are.



https://reviews.llvm.org/D36712