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

[Jacques Pienaar via llvm-dev]

Lanai side looks fine to me.

Thanks,

Jacques

On Tue, Nov 8, 2016 at 3:34 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161109/3d9c782f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4847 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161109/3d9c782f/attachment.bin>