Re: GCC update increased the file size by 4x on PowerPC port

[Felipe Gohring <lipee36 at gmail dot com>]

A complement to this. I was able to successfully execute my tests with 8.2
What it took was to remove all debug flags. Which lead me to another
question: how can GCC 8.2 generate SO MUCH extra information, when compared
to 6.3? The size difference I was having (stated on the original message)
is regarding the stuff created to debug. When loading this amount of
information into QeMU (I am loading each portion of my code on specific
memory regions) I was having a memory overlap, as debugging info was not
being take into account.

On Mon, Jan 7, 2019 at 1:59 PM Felipe Gohring <lipee36@gmail.com> wrote:

> Thanks for the replies.
>
>
> On Mon, Jan 7, 2019 at 12:23 PM Segher Boessenkool <
> segher@kernel.crashing.org> wrote:
>
>> Hi,
>>
>> On Mon, Jan 07, 2019 at 11:14:12AM -0500, Felipe Gohring wrote:
>> > Now, my question is related to the generated code. When using V6.3, I
>> had
>> > files of about 10k. After upgrading to V8.2, the very same file has more
>> > than 40k. Why is that? Please keep in mind that I am using exactly the
>> same
>> > compilation flags (*-m32 -mmfpgpr -mabi=spe -mfloat-gprs=double
>> -nostdlib
>> > -ffreestanding -fno-builtin -O0 -g3 -std=c11 -Wno-packed-bitfield-compat
>> > -Wall -Werror*) and source code, the only thing changing is the compiler
>> > version. I wouldn't mind having a memory footprint a bit bigger, but the
>> > overhead added is beyond acceptable.
>>
>> If you care about code size, you want -O1 or -Os, not -O0.
>>
>> I don't, I was just surprised! But indeed, the difference was mostly due
> to -g3 flag. Without debug flags the size is almos (>5%) the same.
>
>
>> And why are you using -mmfpgpr?  That option doesn't do anything for
>> anything
>> targetting SPE, but for some reason many people use it?
>>
>> I assumed it was needed, in order for SPE to use the general purpose
> registers properly. removed them.
>
>
>> > Further, besides the crazy sizes, some applications are breaking when
>> using
>> > the updated compiler version, even though I am not having any warning
>> > neither error (*-Wall -Werror)*. How come, as the ABI should not be
>> broken
>> > even with a different compiler version?
>>
>> Use -Wall -Wextra instead...  But your code may be doing many more things
>> wrong than those warnings can detect.  You could try -fno-strict-aliasing
>> for example.
>>
>> Using -Wall -Wextra a few new warnings were found and I have corrected
> them already. Still, even with -fno-strict-aliasing applications do not
> work with the new compiler version
>
>>
>> Segher
>>
>
>
> --
> Felipe GM
>


-- 
Felipe GM