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

[Krzysztof Parzyszek via llvm-dev]

The idea on Hexagon is that const objects should not be placed in a 
writable section, and there is no such thing as read-only small-data on 
Hexagon (we only have one global pointer register).
At the same time, there are instructions that load large integer 
immediates into registers (CONST32/CONST64), and they way they do it is 
by loading them from small-data (where the assembler/linker would place 
them), so this is not something carved in silicone...

One issue we had was that small-data filled up quite quickly for large 
applications, so we needed some heuristics to limit the amount of stuff 
that ended up there.

-Krzysztof



On 11/8/2016 5:23 PM, Jack Andersen via llvm-dev wrote:
> On second thought, a third arg will add a burdensome caller constraint in several areas.
>
> The GlobalObject itself has isConstant(), so that should be sufficient for rejecting ReadOnly cases (Hexagon does it already).
>
>> On 8 Nov 2016, at 12:33, Jack Andersen <jackoalan at gmail.com> wrote:
>>
>> Oh, one thing I forgot to mention:
>>
>> ReadOnly objects are also counted as small data globals on PPC (on top of BSS, Data, Common). That's what the r2 base is for (.sdata2, defined to be constant data). 32-bit immediate loads take 2 ops minimum on PPC, so even constant loading benefits from small data.
>>
>> It'd be handy to add a third argument containing what kind would normally be returned:
>> isGlobalInSmallSectionKind(GO, TM, <nominal-kind-expr>)
>>
>> If a ReadOnly global is better emitted as instruction immediates, then the target can return `false` right then and there.
>>
>>> On Nov 8, 2016, at 07:21, Simon Dardis <Simon.Dardis at imgtec.com> wrote:
>>>
>>> isGlobalInSmallSectionKind
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>