<div dir="ltr">Would these pragmas be translation-unit global or could they be pushed and popped like the MSVC pragmas?<div><br></div><div>If two TUs are combined through LTO, can the two TUs have different bss and data sections?</div><div><br></div><div>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><br></div><div>Here is a C++ example where, after optimization, a global may end up in .bss instead of .data:</div><div>// c++</div><div><div>static int f() { return 0; }</div><div>static int x = f();</div><div>int *g() { return &x; }</div></div><div><br></div><div>After global opt we get this:</div><div><div>@_ZL1x = internal global i32 0, align 4</div></div><div><br></div><div>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"><br><div class="gmail_quote">On Thu, Mar 2, 2017 at 11:35 AM, Javed Absar via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





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

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