llvm dev - Nov 2016 - [MC] Target-Independent Small Data Section Handling

Just pinging this patch for review, particularly from PPC maintainers:

https://reviews.llvm.org/D26344

It's now rebased for the latest master commits, `check-all` test results
match those of the upstream base.

There is also a clang driver patch, extending PPC target support for the `-G`
flag:

https://reviews.llvm.org/D26345

And lld patch implementing the _SDA_BASE_ symbols and includes an end-to-end
test for small data relocations:

https://reviews.llvm.org/D26346

I don't have commit access either, so I could use some help with that when
ready.

Thanks,
Jack
> On 8 Nov 2016, at 07:21, Simon Dardis <Simon.Dardis at imgtec.com>
wrote:
> 
> Hi Jack,
> 
> Thanks for working on this, I think you have the right approach by making
this more general.
> 
> I've been looking at your posted patch and I'll post some comments
there.
> 
> Thanks,
> Simon
> 
> 
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Jack Andersen via llvm-dev
> Sent: 08 November 2016 02:48
> To: llvm-dev
> Subject: [llvm-dev] [MC] Target-Independent Small Data Section Handling
> 
> I've prepared a preliminary patch with the intention of implementing
PPC-EABI subtarget features for applications that run in a standalone embedded
environment.
> 
> https://reviews.llvm.org/D26344
> 
> The most significant difference compared with the SVR4 ABI is the use of
SDA (small data area). This allows full-word constants and data to be grouped
into small-data sections accessed using relocated addresses; calculated relative
to the non-volatile values loaded into base registers r13 and r2 by the runtime
init (similar to gp_rel on MIPS). Only a single load/store instruction is needed
to contain the relocated address.
> 
> The MIPS target already has a solid approach for handling small global
variables in its TargetLoweringObjectFile subclass. Also, the clang driver
responds to the `-G <bytes>` flag so the user can define a cutoff size
other than 8 (or 0 to disable small data altogether).
> 
> It seems the Hexagon and Lanai targets duplicate much of the
IsGlobalInSmallSection handling from the MIPS target, but perform the same basic
classification tasks:
> 
> 1. Pass GlobalObject to target-declared IsGlobalInSmallSection. 
>    If it's a declaration, skip to step 4.
> 2. Pass GlobalObject to target-independent 
>    TargetLoweringObjectFile::getKindForGlobal.
> 3. Ensure the returned SectionKind is Data, BSS or Common.
> 4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl, 
>    which scrutinizes the object's type for the specific architecture.
> 
> I believe this redundant implementation between targets can be reduced by
giving SectionKind an 'isSmallKind' bit (OR'd with 0x80). This
provides a much clearer (and cached) predicate that ISel lowering can take
advantage of when a small data load/store must be generated. The existing
predicates in SectionKind may be modified to use the underlying Kind (AND-ing
with 0x7f), so existing ISel behaviors are mostly unchanged.
> 
> The proposed target-independent small data classification has 2 usage
avenues depending on the context:
> 
> For all GlobalObjects:
> 
> 1. Pass GlobalObject to target-independent 
>    TargetLoweringObjectFile::isGlobalInSmallSection. If it's a
>    declaration, make a virtual call to a new method named
>    TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing 
>    target-specific scrutiny) and return the result early.
> 2. Pass to TargetLoweringObjectFile::getKindForGlobal. 
>    If the Kind is Data, BSS or Common, make a virtual call to
>    TargetLoweringObjectFile::isGlobalInSmallSectionKind just before 
>    returning the SectionKind. If true is returned, set the
'isSmallKind'
>    bit in the returned SectionKind.
> 3. Return the result of the isSmallKind() predicate from 
>    isGlobalInSmallSection
> 
> If the GlobalObject is known to be a definition, the process is even
simpler:
> 
> 1. Pass GlobalObject to TargetLoweringObjectFile::getKindForGlobal 
>    (which calls isGlobalInSmallSectionKind in turn).
> 2. Act on isSmallKind() predicate (and conveniently get the 
>    SectionKind at the same time).
> 
> I feel that the SectionKind modification is the best route, since it's
already used to uniquely classify constant merge sections. Even though small
data sections are linked in the same manner as their 'regular'
counterparts, there must be a clear distinction when producing memory access
code (and obviously selecting the target section to allocate in).
> 
> I'd like some input from PowerPC, MIPS, Hexagon and Lanai maintainers
to ensure this approach accommodates their targets appropriately.

----- Original Message -----
> From: "Jack Andersen via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Wednesday, November 16, 2016 10:39:53 PM
> Subject: Re: [llvm-dev] [MC] Target-Independent Small Data Section Handling
> 
> Just pinging this patch for review, particularly from PPC
> maintainers:
Hi Jack, thanks for working on this. I'll look at your patches next week.

 -Hal
> 
> https://reviews.llvm.org/D26344
> 
> It's now rebased for the latest master commits, `check-all` test
> results match those of the upstream base.
> 
> There is also a clang driver patch, extending PPC target support for
> the `-G` flag:
> 
> https://reviews.llvm.org/D26345
> 
> And lld patch implementing the _SDA_BASE_ symbols and includes an
> end-to-end test for small data relocations:
> 
> https://reviews.llvm.org/D26346
> 
> I don't have commit access either, so I could use some help with that
> when ready.
> 
> Thanks,
> Jack
> 
> > On 8 Nov 2016, at 07:21, Simon Dardis <Simon.Dardis at
imgtec.com>
> > wrote:
> > 
> > Hi Jack,
> > 
> > Thanks for working on this, I think you have the right approach by
> > making this more general.
> > 
> > I've been looking at your posted patch and I'll post some
comments
> > there.
> > 
> > Thanks,
> > Simon
> > 
> > 
> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf
> > Of Jack Andersen via llvm-dev
> > Sent: 08 November 2016 02:48
> > To: llvm-dev
> > Subject: [llvm-dev] [MC] Target-Independent Small Data Section
> > Handling
> > 
> > I've prepared a preliminary patch with the intention of
> > implementing PPC-EABI subtarget features for applications that run
> > in a standalone embedded environment.
> > 
> > https://reviews.llvm.org/D26344
> > 
> > The most significant difference compared with the SVR4 ABI is the
> > use of SDA (small data area). This allows full-word constants and
> > data to be grouped into small-data sections accessed using
> > relocated addresses; calculated relative to the non-volatile
> > values loaded into base registers r13 and r2 by the runtime init
> > (similar to gp_rel on MIPS). Only a single load/store instruction
> > is needed to contain the relocated address.
> > 
> > The MIPS target already has a solid approach for handling small
> > global variables in its TargetLoweringObjectFile subclass. Also,
> > the clang driver responds to the `-G <bytes>` flag so the user
can
> > define a cutoff size other than 8 (or 0 to disable small data
> > altogether).
> > 
> > It seems the Hexagon and Lanai targets duplicate much of the
> > IsGlobalInSmallSection handling from the MIPS target, but perform
> > the same basic classification tasks:
> > 
> > 1. Pass GlobalObject to target-declared IsGlobalInSmallSection.
> >    If it's a declaration, skip to step 4.
> > 2. Pass GlobalObject to target-independent
> >    TargetLoweringObjectFile::getKindForGlobal.
> > 3. Ensure the returned SectionKind is Data, BSS or Common.
> > 4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl,
> >    which scrutinizes the object's type for the specific
> >    architecture.
> > 
> > I believe this redundant implementation between targets can be
> > reduced by giving SectionKind an 'isSmallKind' bit (OR'd
with
> > 0x80). This provides a much clearer (and cached) predicate that
> > ISel lowering can take advantage of when a small data load/store
> > must be generated. The existing predicates in SectionKind may be
> > modified to use the underlying Kind (AND-ing with 0x7f), so
> > existing ISel behaviors are mostly unchanged.
> > 
> > The proposed target-independent small data classification has 2
> > usage avenues depending on the context:
> > 
> > For all GlobalObjects:
> > 
> > 1. Pass GlobalObject to target-independent
> >    TargetLoweringObjectFile::isGlobalInSmallSection. If it's a
> >    declaration, make a virtual call to a new method named
> >    TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing
> >    target-specific scrutiny) and return the result early.
> > 2. Pass to TargetLoweringObjectFile::getKindForGlobal.
> >    If the Kind is Data, BSS or Common, make a virtual call to
> >    TargetLoweringObjectFile::isGlobalInSmallSectionKind just before
> >    returning the SectionKind. If true is returned, set the
> >    'isSmallKind'
> >    bit in the returned SectionKind.
> > 3. Return the result of the isSmallKind() predicate from
> >    isGlobalInSmallSection
> > 
> > If the GlobalObject is known to be a definition, the process is
> > even simpler:
> > 
> > 1. Pass GlobalObject to TargetLoweringObjectFile::getKindForGlobal
> >    (which calls isGlobalInSmallSectionKind in turn).
> > 2. Act on isSmallKind() predicate (and conveniently get the
> >    SectionKind at the same time).
> > 
> > I feel that the SectionKind modification is the best route, since
> > it's already used to uniquely classify constant merge sections.
> > Even though small data sections are linked in the same manner as
> > their 'regular' counterparts, there must be a clear
distinction
> > when producing memory access code (and obviously selecting the
> > target section to allocate in).
> > 
> > I'd like some input from PowerPC, MIPS, Hexagon and Lanai
> > maintainers to ensure this approach accommodates their targets
> > appropriately.
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

Thanks Hal,

Something I think needs to be determined is how much driver compatibility with
GCC is desired. This patch shares command-line flags that were added for MIPS
backend (`-G`, `-G=`, `-msmall-data-threshold=`). I feel this simplified usage
is enough for most cases, but GCC offers several `-msdata*` flags to tune the
ABI particulars (as well as a `-meabi` flag, which LLVM represents as the fourth
TargetTriple component).

Be default, PPC-EABI targets on GCC will allocate small data entries in the
small sections, but _won't_ actually use SDA21 relocation to access them out
of memory. This patch assumes the opposite as long as EABI is in the Triple. Of
course, this behavior can be worked around by issuing `-G 0` to disable small
data relocation.

Really, it's just a question of whether a 64K small-section limit is
acceptable to an EABI application by default.

-Jack
> On 18 Nov 2016, at 08:39, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Jack Andersen via llvm-dev" <llvm-dev at
lists.llvm.org>
>> To: "llvm-dev" <llvm-dev at lists.llvm.org>
>> Sent: Wednesday, November 16, 2016 10:39:53 PM
>> Subject: Re: [llvm-dev] [MC] Target-Independent Small Data Section
Handling
>> 
>> Just pinging this patch for review, particularly from PPC
>> maintainers:
> 
> Hi Jack, thanks for working on this. I'll look at your patches next
week.
> 
> -Hal
> 
>> 
>> https://reviews.llvm.org/D26344
>> 
>> It's now rebased for the latest master commits, `check-all` test
>> results match those of the upstream base.
>> 
>> There is also a clang driver patch, extending PPC target support for
>> the `-G` flag:
>> 
>> https://reviews.llvm.org/D26345
>> 
>> And lld patch implementing the _SDA_BASE_ symbols and includes an
>> end-to-end test for small data relocations:
>> 
>> https://reviews.llvm.org/D26346
>> 
>> I don't have commit access either, so I could use some help with
that
>> when ready.
>> 
>> Thanks,
>> Jack
>> 
>>> On 8 Nov 2016, at 07:21, Simon Dardis <Simon.Dardis at
imgtec.com>
>>> wrote:
>>> 
>>> Hi Jack,
>>> 
>>> Thanks for working on this, I think you have the right approach by
>>> making this more general.
>>> 
>>> I've been looking at your posted patch and I'll post some
comments
>>> there.
>>> 
>>> Thanks,
>>> Simon
>>> 
>>> 
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf
>>> Of Jack Andersen via llvm-dev
>>> Sent: 08 November 2016 02:48
>>> To: llvm-dev
>>> Subject: [llvm-dev] [MC] Target-Independent Small Data Section
>>> Handling
>>> 
>>> I've prepared a preliminary patch with the intention of
>>> implementing PPC-EABI subtarget features for applications that run
>>> in a standalone embedded environment.
>>> 
>>> https://reviews.llvm.org/D26344
>>> 
>>> The most significant difference compared with the SVR4 ABI is the
>>> use of SDA (small data area). This allows full-word constants and
>>> data to be grouped into small-data sections accessed using
>>> relocated addresses; calculated relative to the non-volatile
>>> values loaded into base registers r13 and r2 by the runtime init
>>> (similar to gp_rel on MIPS). Only a single load/store instruction
>>> is needed to contain the relocated address.
>>> 
>>> The MIPS target already has a solid approach for handling small
>>> global variables in its TargetLoweringObjectFile subclass. Also,
>>> the clang driver responds to the `-G <bytes>` flag so the
user can
>>> define a cutoff size other than 8 (or 0 to disable small data
>>> altogether).
>>> 
>>> It seems the Hexagon and Lanai targets duplicate much of the
>>> IsGlobalInSmallSection handling from the MIPS target, but perform
>>> the same basic classification tasks:
>>> 
>>> 1. Pass GlobalObject to target-declared IsGlobalInSmallSection.
>>>   If it's a declaration, skip to step 4.
>>> 2. Pass GlobalObject to target-independent
>>>   TargetLoweringObjectFile::getKindForGlobal.
>>> 3. Ensure the returned SectionKind is Data, BSS or Common.
>>> 4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl,
>>>   which scrutinizes the object's type for the specific
>>>   architecture.
>>> 
>>> I believe this redundant implementation between targets can be
>>> reduced by giving SectionKind an 'isSmallKind' bit
(OR'd with
>>> 0x80). This provides a much clearer (and cached) predicate that
>>> ISel lowering can take advantage of when a small data load/store
>>> must be generated. The existing predicates in SectionKind may be
>>> modified to use the underlying Kind (AND-ing with 0x7f), so
>>> existing ISel behaviors are mostly unchanged.
>>> 
>>> The proposed target-independent small data classification has 2
>>> usage avenues depending on the context:
>>> 
>>> For all GlobalObjects:
>>> 
>>> 1. Pass GlobalObject to target-independent
>>>   TargetLoweringObjectFile::isGlobalInSmallSection. If it's a
>>>   declaration, make a virtual call to a new method named
>>>   TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing
>>>   target-specific scrutiny) and return the result early.
>>> 2. Pass to TargetLoweringObjectFile::getKindForGlobal.
>>>   If the Kind is Data, BSS or Common, make a virtual call to
>>>   TargetLoweringObjectFile::isGlobalInSmallSectionKind just before
>>>   returning the SectionKind. If true is returned, set the
>>>   'isSmallKind'
>>>   bit in the returned SectionKind.
>>> 3. Return the result of the isSmallKind() predicate from
>>>   isGlobalInSmallSection
>>> 
>>> If the GlobalObject is known to be a definition, the process is
>>> even simpler:
>>> 
>>> 1. Pass GlobalObject to TargetLoweringObjectFile::getKindForGlobal
>>>   (which calls isGlobalInSmallSectionKind in turn).
>>> 2. Act on isSmallKind() predicate (and conveniently get the
>>>   SectionKind at the same time).
>>> 
>>> I feel that the SectionKind modification is the best route, since
>>> it's already used to uniquely classify constant merge sections.
>>> Even though small data sections are linked in the same manner as
>>> their 'regular' counterparts, there must be a clear
distinction
>>> when producing memory access code (and obviously selecting the
>>> target section to allocate in).
>>> 
>>> I'd like some input from PowerPC, MIPS, Hexagon and Lanai
>>> maintainers to ensure this approach accommodates their targets
>>> appropriately.
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory

Bumping this again.

Rebased against upstream master with some minor consistency improvements.

Thanks!
-Jack
> On 18 Nov 2016, at 08:39, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Jack Andersen via llvm-dev" <llvm-dev at
lists.llvm.org>
>> To: "llvm-dev" <llvm-dev at lists.llvm.org>
>> Sent: Wednesday, November 16, 2016 10:39:53 PM
>> Subject: Re: [llvm-dev] [MC] Target-Independent Small Data Section
Handling
>> 
>> Just pinging this patch for review, particularly from PPC
>> maintainers:
> 
> Hi Jack, thanks for working on this. I'll look at your patches next
week.
> 
> -Hal
> 
>> 
>> https://reviews.llvm.org/D26344
>> 
>> It's now rebased for the latest master commits, `check-all` test
>> results match those of the upstream base.
>> 
>> There is also a clang driver patch, extending PPC target support for
>> the `-G` flag:
>> 
>> https://reviews.llvm.org/D26345
>> 
>> And lld patch implementing the _SDA_BASE_ symbols and includes an
>> end-to-end test for small data relocations:
>> 
>> https://reviews.llvm.org/D26346
>> 
>> I don't have commit access either, so I could use some help with
that
>> when ready.
>> 
>> Thanks,
>> Jack
>> 
>>> On 8 Nov 2016, at 07:21, Simon Dardis <Simon.Dardis at
imgtec.com>
>>> wrote:
>>> 
>>> Hi Jack,
>>> 
>>> Thanks for working on this, I think you have the right approach by
>>> making this more general.
>>> 
>>> I've been looking at your posted patch and I'll post some
comments
>>> there.
>>> 
>>> Thanks,
>>> Simon
>>> 
>>> 
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf
>>> Of Jack Andersen via llvm-dev
>>> Sent: 08 November 2016 02:48
>>> To: llvm-dev
>>> Subject: [llvm-dev] [MC] Target-Independent Small Data Section
>>> Handling
>>> 
>>> I've prepared a preliminary patch with the intention of
>>> implementing PPC-EABI subtarget features for applications that run
>>> in a standalone embedded environment.
>>> 
>>> https://reviews.llvm.org/D26344
>>> 
>>> The most significant difference compared with the SVR4 ABI is the
>>> use of SDA (small data area). This allows full-word constants and
>>> data to be grouped into small-data sections accessed using
>>> relocated addresses; calculated relative to the non-volatile
>>> values loaded into base registers r13 and r2 by the runtime init
>>> (similar to gp_rel on MIPS). Only a single load/store instruction
>>> is needed to contain the relocated address.
>>> 
>>> The MIPS target already has a solid approach for handling small
>>> global variables in its TargetLoweringObjectFile subclass. Also,
>>> the clang driver responds to the `-G <bytes>` flag so the
user can
>>> define a cutoff size other than 8 (or 0 to disable small data
>>> altogether).
>>> 
>>> It seems the Hexagon and Lanai targets duplicate much of the
>>> IsGlobalInSmallSection handling from the MIPS target, but perform
>>> the same basic classification tasks:
>>> 
>>> 1. Pass GlobalObject to target-declared IsGlobalInSmallSection.
>>>   If it's a declaration, skip to step 4.
>>> 2. Pass GlobalObject to target-independent
>>>   TargetLoweringObjectFile::getKindForGlobal.
>>> 3. Ensure the returned SectionKind is Data, BSS or Common.
>>> 4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl,
>>>   which scrutinizes the object's type for the specific
>>>   architecture.
>>> 
>>> I believe this redundant implementation between targets can be
>>> reduced by giving SectionKind an 'isSmallKind' bit
(OR'd with
>>> 0x80). This provides a much clearer (and cached) predicate that
>>> ISel lowering can take advantage of when a small data load/store
>>> must be generated. The existing predicates in SectionKind may be
>>> modified to use the underlying Kind (AND-ing with 0x7f), so
>>> existing ISel behaviors are mostly unchanged.
>>> 
>>> The proposed target-independent small data classification has 2
>>> usage avenues depending on the context:
>>> 
>>> For all GlobalObjects:
>>> 
>>> 1. Pass GlobalObject to target-independent
>>>   TargetLoweringObjectFile::isGlobalInSmallSection. If it's a
>>>   declaration, make a virtual call to a new method named
>>>   TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing
>>>   target-specific scrutiny) and return the result early.
>>> 2. Pass to TargetLoweringObjectFile::getKindForGlobal.
>>>   If the Kind is Data, BSS or Common, make a virtual call to
>>>   TargetLoweringObjectFile::isGlobalInSmallSectionKind just before
>>>   returning the SectionKind. If true is returned, set the
>>>   'isSmallKind'
>>>   bit in the returned SectionKind.
>>> 3. Return the result of the isSmallKind() predicate from
>>>   isGlobalInSmallSection
>>> 
>>> If the GlobalObject is known to be a definition, the process is
>>> even simpler:
>>> 
>>> 1. Pass GlobalObject to TargetLoweringObjectFile::getKindForGlobal
>>>   (which calls isGlobalInSmallSectionKind in turn).
>>> 2. Act on isSmallKind() predicate (and conveniently get the
>>>   SectionKind at the same time).
>>> 
>>> I feel that the SectionKind modification is the best route, since
>>> it's already used to uniquely classify constant merge sections.
>>> Even though small data sections are linked in the same manner as
>>> their 'regular' counterparts, there must be a clear
distinction
>>> when producing memory access code (and obviously selecting the
>>> target section to allocate in).
>>> 
>>> I'd like some input from PowerPC, MIPS, Hexagon and Lanai
>>> maintainers to ensure this approach accommodates their targets
>>> appropriately.
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory