[llvm-dev] AARCH64 Code Size regression between 6/7

[Rob via llvm-dev]

Whoops, forgot an import part of my compile flags :)

"clang --target=aarch64-linux-elf -Oz -c"

On Wed, May 15, 2019 at 12:21 PM Rob <rrmills at gmail.com> wrote:

> I can't provide my exact problematic code, but here is a trivial example
> of a .c file that produces different results in clang 6 vs 7.  The compiled
> output from v7 generates two extra adrp instructions.  I compiled just with
> "clang -Oz -c" for both versions.
>
> Rob M
>
>
>
> On Wed, May 15, 2019 at 11:39 AM Florian Hahn <florian_hahn at apple.com>
> wrote:
>
>> Hi,
>>
>> > On May 15, 2019, at 16:27, Rob via llvm-dev <llvm-dev at lists.llvm.org>
>> wrote:
>> >
>> > I am developing in C for an extremely memory constrained AARCH64
>> embedded environment.  Sometime between llvm 6 and 7, I'm seeing a code
>> size regression when I make multiple accesses into a global struct.
>> Specifically, I have functions that perform several reads/writes into this
>> global struct.
>> >
>> > In older versions (5/6)
>> > - a single ADRP/ADD combo is issued at the beginning of a function to
>> get my structure address into a register
>> > - that register is preserved throughout the function
>> > - subsequent accesses into this structure are done as LDR/STR with
>> offset from the preserved register
>> >
>> > In later versions (7/8)
>> > - the ADRP/ADD combo is performed every time I try to access something
>> inside the struct.
>> >
>> > The net result is slightly larger code that has the potential to cause
>> me issues. There are plenty of unused registers that could be used for the
>> purpose of not constantly re-loading the address of my struct.  My current
>> suspicion is that later versions are presuming fewer registers are not
>> being preserved by other function calls, and therefore can't be relied upon
>> to hold the address of my struct.  Assuming this is right, is there some
>> way to encourage the behavior of the older versions?
>>
>>
>> Is the IR that gets fed into the backend equivalent between 5/6 and 7/8?
>> This sounds like something could go wrong earlier, e.g. failing to
>> eliminate congruent address computations in GVN.
>>
>> In any case, to get to the bottom of this, a reproducer would be helpful.
>>
>> Cheers,
>> Florian
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190515/717f912e/attachment.html>