efriedma added a comment.
> If there is no section given explicitly, there is function
> SelectSectionForGlobal that will determine the section based on the
> properties of the global. If there is code that only sees the declaration,
> but needs to know the section, it will get it from that fun
This revision was automatically updated to reflect the committed changes.
Closed by commit rL311459: Emit section information for extern variables
(authored by erichkeane).
Changed prior to commit:
https://reviews.llvm.org/D36712?vs=112172&id=112180#toc
Repository:
rL LLVM
https://reviews.l
eandrews updated this revision to Diff 112172.
eandrews added a comment.
Updated the documentation to explicitly state that section information for a
variable can be explicit or inferred.
https://reviews.llvm.org/D36712
Files:
docs/LangRef.rst
Index: docs/LangRef.rst
==
sdardis added a comment.
> One suggestion inline for the wording inline, the important part is making
> explicit
The important part is making explicit that section information for a variable
can be explicit or inferred.
https://reviews.llvm.org/D36712
__
sdardis accepted this revision.
sdardis added a comment.
This revision is now accepted and ready to land.
I agree with @kparzysz here. If there is a mis-match between the declaration
and definition, there are cases where undesirable behaviour (as such) will not
occur depending on how the mismatc
eandrews added a comment.
In https://reviews.llvm.org/D36712#843414, @kparzysz wrote:
> The problem is that the mismatch between sections does not have to lead to
> any undesirable behavior. Whether it does or not depends on a particular
> case. I think we should be consistent though---if we
eandrews updated this revision to Diff 111388.
eandrews added a comment.
Updated the patch to include Krzysztof's comment about explicitly stating
undefined behavior for section information mismatch in global variable
declaration and definition. This should cover the case where section is
expli
kparzysz added a comment.
The problem is that the mismatch between sections does not have to lead to any
undesirable behavior. Whether it does or not depends on a particular case. I
think we should be consistent though---if we decide that a mismatch between the
section for a declaration and t
kparzysz added a comment.
In https://reviews.llvm.org/D36712#843387, @eandrews wrote:
> Does this result in unexpected behavior though? Won't this just result in the
> global being defined in the specified section?
If there is no section given explicitly, there is function
SelectSectionForGlo
eandrews added a comment.
In https://reviews.llvm.org/D36712#842477, @kparzysz wrote:
> In the cases when the section is explicitly given on a definition, it was
> likely imposed by something like the "section" attribute in the source. I
> don't think it's unreasonable to expect that the declar
eandrews updated this revision to Diff 111341.
eandrews added a comment.
Corrected spelling error.
https://reviews.llvm.org/D36712
Files:
docs/LangRef.rst
Index: docs/LangRef.rst
===
--- docs/LangRef.rst
+++ docs/LangRef.rst
@@
efriedma added inline comments.
Comment at: docs/LangRef.rst:628
+information. Attaching section information to an external declaration is an
+assertion that it's definition is located in the specified section. If the
+definition is located in a different section, the behavior
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:
> > >
kparzysz added a comment.
In https://reviews.llvm.org/D36712#842433, @efriedma wrote:
> I can't see how "undefined behavior" could possibly be the right answer in
> that case. Every definition has to end up in some section eventually, and in
> many cases we don't know what section that will be
eandrews updated this revision to Diff 111227.
eandrews added a comment.
I updated the documentation to include Simon's comments. I wasn't sure whether
to include the line about section information being retained in LLVM IR, since
Eli mentioned it could vary for different front-ends. I have incl
efriedma added a comment.
> 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 can't see how "undefined behavior" could possibly be the right answer in that
case. Every definition ha
kparzysz 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.
+
sdardis wrote:
> efriedma wrote:
> > This doesn't really ex
sdardis requested changes to this revision.
sdardis added a reviewer: kparzysz.
sdardis added a comment.
This revision now requires changes to proceed.
+kparzysz as Hexagon also makes use of the small data section.
Comment at: docs/LangRef.rst:629
+corresponding to the LLVM mod
efriedma 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.
+
This doesn't really explain the part that matters. For Lang
eandrews created this revision.
Update IR generated to retain section information for external declarations.
This is related to https://reviews.llvm.org/D36487
https://reviews.llvm.org/D36712
Files:
docs/LangRef.rst
Index: docs/LangRef.rst
==
20 matches
Mail list logo
