llvm dev - Mar 2017 - [cfe-dev] proposal - pragma section directive in clang

Hi Reid,

Unfortunately yes, it is.
> If we do go with approach 3, I'd recommend adding a single metadata
attachment that controls all sections a global could possibly live in
(text, data, rdata, bss).

I agree with this, although I think using metadata here wouldn't be right -
don't we need to use attributes when dropping metadata would cause
miscompiles?

I was considering adding an attributeset to global variables, so we'd have
something like:

global i32* @g = i32 0, #0

#0 = attributes {bss_seg="...", text_seg="...",
data_seg="..."}

Cheers,

James


On Tue, 14 Mar 2017 at 18:15 Reid Kleckner <rnk at google.com> wrote:
> Is that actually an important use case? It sounded like it wasn't, and
if
> we pursue option 3, we need to staple three pieces of data to every global:
> the default section to use if the global would live in .data, .rdata, or
> .bss.
>
> My main goal here is to eliminate complexity for what is for most users
> probably going to be a very niche feature, so if we can simply document
> that the pragma affects all globals in the TU and call it a day, I'd be
> happy with that.
>
> If we do go with approach 3, I'd recommend adding a single metadata
> attachment that controls all sections a global could possibly live in
> (text, data, rdata, bss). This avoids having three attachments with three
> separate hashtable entries on every global variable we emit when the pragma
> is active.
>
> On Tue, Mar 14, 2017 at 2:25 AM, Javed Absar <Javed.Absar at arm.com>
wrote:
>
> Thanks Reid/Jonathon for your replies.
>
>
> Reid,
>
> An important case against module level flags is that it wont allow
> changing or  resetting section names e.g.
>
>
> int a;
>
> #pragma clang section bss = "xyz"
>
> int b;
>
>
> In case above, users would like to see only 'b' placed in
'xyz' and
> not 'a' as well.
>
> Link pointed to by Jonathon seems to require same behavior.
>
>
> Jonathon,
>
> We are happy to revise the spelling to -
>
> #pragma clang section bss = "xyz"
>
> as you propose.
> Best Regards, Javed.
>
> *From:* Jonathan Roelofs <jonathan at codesourcery.com>
> *Sent:* 13 March 2017 18:12:57
> *To:* James Molloy; Reid Kleckner; Javed Absar
> *Cc:* LLVM Dev; nd; cfe-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] [cfe-dev] proposal - pragma section directive
> in clang
>
>
>
> On 3/10/17 2:47 AM, James Molloy via llvm-dev wrote:
> > +llvm-dev properly this time.
> >
> > On Fri, 10 Mar 2017 at 09:42 James Molloy <james at
jamesmolloy.co.uk
> > <mailto:james at jamesmolloy.co.uk <james at
jamesmolloy.co.uk>>> wrote:
> >
>
> >
> >     The documentation is here:
> >
>
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html
> >
> >     ** Proposed syntax and (vague) semantics **
> >
> >     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.
> >
> >       #pragma clang section bss(".mybss")
rodata(".myrodata")
> >     data(".mydata") text(".mytext")
>
> There's some prior art in the GreenHills compiler too, where the
example
> above would be spelled:
>
>      #pragma ghs section bss=".mybss",
rodata=".myrodata",
> data=".mydata", text=".mytext"
>
> Maybe it's worth using that syntax, i.e:
>
>      #pragma clang section bss=".mybss",
rodata=".myrodata",
> data=".mydata", text=".mytext"
>
> Alternatively, supporting vendor-specific spellings might be useful, if
> there's a consistency argument to be made for clang doing it its own
way.
>
> Docs are pages 108/109 here:
> http://www.ece.ualberta.ca/~cmpe490/documents/ghs/build_arm.pdf
>
>
> Jon
>
> >
> >     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.
> >
> >     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).
> >
> >     This pragma is only defined to work sensibly for ELF targets.
> >
>
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/6fcc87e7/attachment.html>

+Justin and Briana, they wanted attributes on GlobalVariables recently for
GPU textures.

On Tue, Mar 14, 2017 at 1:02 PM, James Molloy <james at jamesmolloy.co.uk>
wrote:
> Hi Reid,
>
> Unfortunately yes, it is.
>
OK.

> > If we do go with approach 3, I'd recommend adding a single
metadata
> attachment that controls all sections a global could possibly live in
> (text, data, rdata, bss).
>
> I agree with this, although I think using metadata here wouldn't be
right
> - don't we need to use attributes when dropping metadata would cause
> miscompiles?
>
I was considering adding an attributeset to global variables, so we'd
have
> something like:
>
We could definitely add AttributeSets to GlobalValue. I'd support that. It
also achieves the optimization goal of not having three attachments for
every global.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/79c99a6e/attachment.html>

Thanks Reid for the support.   Welcome Justin/Briana to the discussion. Happy to
hear that AttributeSets attached to GlobalVariable will be useful for other
purposes as well.


From: Reid Kleckner [mailto:rnk at google.com]
Sent: 14 March 2017 20:15
To: James Molloy <james at jamesmolloy.co.uk>; Justin Lebar <jlebar at
google.com>; Briana Grace <brianagrace at google.com>
Cc: Javed Absar <Javed.Absar at arm.com>; Jonathan Roelofs <jonathan at
codesourcery.com>; LLVM Dev <llvm-dev at lists.llvm.org>; nd <nd at
arm.com>; cfe-dev at lists.llvm.org
Subject: Re: [llvm-dev] [cfe-dev] proposal - pragma section directive in clang

+Justin and Briana, they wanted attributes on GlobalVariables recently for GPU
textures.

On Tue, Mar 14, 2017 at 1:02 PM, James Molloy <james at
jamesmolloy.co.uk<mailto:james at jamesmolloy.co.uk>> wrote:
Hi Reid,

Unfortunately yes, it is.

OK.
> If we do go with approach 3, I'd recommend adding a single metadata
attachment that controls all sections a global could possibly live in (text,
data, rdata, bss).
I agree with this, although I think using metadata here wouldn't be right -
don't we need to use attributes when dropping metadata would cause
miscompiles?
I was considering adding an attributeset to global variables, so we'd have
something like:

We could definitely add AttributeSets to GlobalValue. I'd support that. It
also achieves the optimization goal of not having three attachments for every
global.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/08cdd100/attachment.html>