<div dir="ltr">+llvm-dev properly this time.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, 10 Mar 2017 at 09:42 James Molloy <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">Hi Reid, all,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">+llvm-dev as this RFC involves changes in Clang and LLVM.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This RFC has stagnated and I think that's partially because the proposal isn't particularly elegant and is light on details. We've been having a rethink and have a slightly different implementation to propose that we (I) hope will be nicer.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">** Rationale (for llvm-dev) **</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The goal of this proposed feature is to provide a migration path toward Clang for developers in the automotive domain. As Javed has mentioned, AUTOSAR, an automotive standard, mandates the use of a #pragma in header files to determine in which sections initialized and uninitialized data get put.</div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This feature is implemented in our legacy ARM Compiler 5 toolchain and we're also aware of GCC forks used across the automotive space that have this feature implemented compatible with the ARM Compiler 5 implementation.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The documentation is here: <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html" class="gmail_msg" target="_blank">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html</a></div><div class="gmail_msg"><br class="gmail_msg"></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg">** Proposed syntax and (vague) semantics **</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As this is a new pragma for Clang and isn't ARM-specific, we've invented a less ARM-specific syntax. Bikeshedding is expected and welcome.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">  #pragma clang section bss(".mybss") rodata(".myrodata") data(".mydata") text(".mytext")</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The pragma applies to all global variable and function declarations from the pragma to the end of the translation unit. The pragma should ideally be pushable and poppable, but that is outside the scope of this RFC. The pragma also applies to static local declarations within functions.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">All global variables and functions affected by this pragma have their default ELF section destinations changed. Globals with __attribute__((section())) are not affected (the attribute trumps the pragma).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This pragma is only defined to work sensibly for ELF targets.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">** Proposed implementation **</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There are, I believe, three possible implementation stategies:</div><div class="gmail_msg">  1) Clang internally sets the "section" on all globals it creates. No changes in LLVM.</div><div class="gmail_msg">  2) Clang sets some module-level attribute describing the default section names. The LLVM backend takes this into account when deciding the section name for a global when it emits it (AsmPrinter).</div><div class="gmail_msg">  3) Clang sets the default section names as attributes on all globals. The LLVM backend takes this into account when deciding the section name for a global when it emits it (AsmPrinter).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(1) and (3) work with LTO. (2) interacts badly with LTO so is discounted.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(1) requires Clang to perform the decision into exactly what section a global will go, which is the wrong place for several previously mentioned reasons (midend optimizations could promote .data -> .bss, clang currently doesn't have the mechanics to test if an initializer is zero or not, LLVM does).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(2) and (3) have the advantage that the section type does not need to be inferred by LLVM from its name. This means we don't need the horrible string matching (m/^.bss./ -> BSS, m/^.data./ -> Data, etc) in the AsmPrinter - users can specify whatever names they like for bss sections without confusing the compiler.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Our previous proposal was (1). We are now proposing (3).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For (3), I think there are three distinct steps, none of which are *particularly* invasive:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">  a) Allow arbitrary attributes on GlobalVariables. Currently these are restricted to Functions only; I believe mainly because noone had a usecase for attributes on variables.</div><div class="gmail_msg">  b) Teach the clang frontend about the new pragma and CodeGen to add the attributes to globals</div><div class="gmail_msg">  c) Teach AsmPrinter to inspect these attributes if they exist and take them into account when choosing sections.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">All comments more than welcome,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">James</div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Fri, 3 Mar 2017 at 09:09 James Molloy <<a href="mailto:james@jamesmolloy.co.uk" class="gmail_msg" target="_blank">james@jamesmolloy.co.uk</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">Hi Reid,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks for your comments. In truth, we don't have a particular requirement for behaviour under LTO or pushability/poppability, so we can define this in terms of what's best for Clang.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As context is always useful, the goal of this proposed feature is to provide a migration path toward Clang for developers in the automotive domain. As Javed has mentioned, AUTOSAR which is an automotive standard, mandates the use of a #pragma in header files to determine in which sections initialized and uninitialized data get put.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This feature is implemented in our legacy ARM Compiler 5 toolchain and we're also aware of GCC forks used across the automotive space that have this feature implemented compatible with the ARM Compiler 5 implementation.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The documentation is here: <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html" class="gmail_msg" target="_blank">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">We do not aim for or anticipate syntax-level compatibility; merely the ability to do something similar in Clang. In particular Clang can't support the "section_type" specifier without significant rewrite, as LLVM decides the section type (NOBITS/PROGBITS) by textual matching on the section name (gross, but the fix is well beyond our scope).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Given that documentation, you can also see why the Microsoft compatibility option *almost* met our requirements - all except the behaviour in this case:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">#pragma bss_seg('.bss.mybss')</div><div class="gmail_msg">int i; // Microsoft extension will put i in .bss.mybss</div><div class="gmail_msg">int j = 0; // Microsoft extension will put j in .data, whereas we really need it in .bss.mybss</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">So to specifically answer your questions:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In ARM Compiler 5, all pragmas are pushable and poppable. Clang doesn't have this feature generally yet, but when/if it does, I don't see why this pragma shouldn't be affected. So yes, we should consider it pushable and poppable.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think the only reasonable behaviour under LTO must be that the two TUs (may) have different bss and data sections. Anything else would be very strange behaviour from the user's perspective.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Your example of a static global migrating from .data into .bss after optimization is interesting. With our proposal to explicitly name sections in IR, this optimization would be inhibited. I personally think that's fine :)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Cheers,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">James</div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Thu, 2 Mar 2017 at 21:42 Reid Kleckner via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Would these pragmas be translation-unit global or could they be pushed and popped like the MSVC pragmas?<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">If two TUs are combined through LTO, can the two TUs have different bss and data sections?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">If the answer to both is "no", then I think we should use a module flag instead of manually setting the section from the frontend.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Here is a C++ example where, after optimization, a global may end up in .bss instead of .data:</div><div class="gmail_msg">// c++</div><div class="gmail_msg"><div class="gmail_msg">static int f() { return 0; }</div><div class="gmail_msg">static int x = f();</div><div class="gmail_msg">int *g() { return &x; }</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">After global opt we get this:</div><div class="gmail_msg"><div class="gmail_msg">@_ZL1x = internal global i32 0, align 4</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Normally LLVM will put this in .bss or use .lcomm for it. Your proposal will put it in the user's data section instead of their bss section. If that's important, we should use a module flag for this.</div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Thu, Mar 2, 2017 at 11:35 AM, Javed Absar via cfe-dev <span dir="ltr" class="gmail_msg"><<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-GB" link="#0563C1" vlink="#954F72" class="gmail_msg">
<div class="m_-1134757355221584237m_415161867628613655m_3187848934551112840m_3527854597707582817WordSection1 gmail_msg">
<p class="MsoNormal gmail_msg"><span style="color:black" class="gmail_msg">Hi all:<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p>
<p class="MsoNormal gmail_msg"><span style="color:black" class="gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p>
<p class="MsoNormal gmail_msg"><span style="color:black" class="gmail_msg">We would like to propose a clang pragma directive to allow specialized section names.<br class="gmail_msg">
The semantics of it could be as follows. The pragma section name is declared in global<br class="gmail_msg">
scope. All global variables and functions get assigned to the corresponding specialized<br class="gmail_msg">
section name if one is present. With this feature, the following code:<br class="gmail_msg">
<br class="gmail_msg">
// foo.c<br class="gmail_msg">
#pragma bss_section(".bss.alpha")<br class="gmail_msg">
#pragma data_section(".data.beta")<br class="gmail_msg">
#pragma code_section(".code.gamma")<br class="gmail_msg">
#pragma const_section(".const.delta")<br class="gmail_msg">
int a;<br class="gmail_msg">
int b=2;<br class="gmail_msg">
const int d = 5;<br class="gmail_msg">
int c(){<br class="gmail_msg">
  return d;<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
..will emit llvm-ir as:<br class="gmail_msg">
<br class="gmail_msg">
target triple = "armv7-arm-none-eabi"<br class="gmail_msg">
@a = global i32 0, section ".bss.alpha", align 4<br class="gmail_msg">
@b = global i32 2, section ".data.beta", align 4<br class="gmail_msg">
@d = constant i32 5, section ".const.delta", align 4<br class="gmail_msg">
<br class="gmail_msg">
; Function Attrs: noinline nounwind<br class="gmail_msg">
define i32 @c() #0 section ".code.gamma" {<br class="gmail_msg">
entry:<br class="gmail_msg">
  ret i32 5<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
This pragma will be very useful for embedded code which<br class="gmail_msg">
need to control where the different sections are placed in memory.<br class="gmail_msg">
<br class="gmail_msg">
Microsoft -fms-extension provides similar feature, but our proposal is for a <br class="gmail_msg">
general use.  Attributes are an alternative that is also currently available,<br class="gmail_msg">
but attributes are applicable only to specific declarations and not entire<br class="gmail_msg">
file. Many real embedded users prefer the pragma option.<br class="gmail_msg">
This will be a welcome enabler for them. Also, </span>AUTOSAR, which is an<u class="gmail_msg"></u><u class="gmail_msg"></u></p>
<p class="MsoNormal gmail_msg">automotive standard mandates use of a #pragma solution over an attribute one<span style="color:black" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
Looking forward to comments and suggestions.<br class="gmail_msg">
</span>Best Regards<span class="m_-1134757355221584237m_415161867628613655m_3187848934551112840HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><u class="gmail_msg"></u><u class="gmail_msg"></u></font></span></p><span class="m_-1134757355221584237m_415161867628613655m_3187848934551112840HOEnZb gmail_msg"><font color="#888888" class="gmail_msg">
<p class="MsoNormal gmail_msg">Javed<u class="gmail_msg"></u><u class="gmail_msg"></u></p>
</font></span></div>
</div>

<br class="gmail_msg">_______________________________________________<br class="gmail_msg">
cfe-dev mailing list<br class="gmail_msg">
<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
cfe-dev mailing list<br class="gmail_msg">
<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="gmail_msg">
</blockquote></div></blockquote></div></blockquote></div></div>