* GCC update increased the file size by 4x on PowerPC port
@ 2019-01-07 16:12 Felipe Gohring
2019-01-07 16:56 ` Xi Ruoyao
2019-01-07 17:23 ` Segher Boessenkool
0 siblings, 2 replies; 6+ messages in thread
From: Felipe Gohring @ 2019-01-07 16:12 UTC (permalink / raw)
To: gcc-help
Hello,
recently, I have updated my GCC PowerPC port from 6.3 to 8.2
As my architecture relies on SPE extension, I am using the SPE brench of
GCC (powerpc-eabispe-*).
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.
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?
So, any direction, advice or comment here would be much appreciated!
Thanks in advance
--
Felipe GM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC update increased the file size by 4x on PowerPC port
2019-01-07 16:12 GCC update increased the file size by 4x on PowerPC port Felipe Gohring
@ 2019-01-07 16:56 ` Xi Ruoyao
2019-01-07 16:59 ` Jonathan Wakely
2019-01-07 17:23 ` Segher Boessenkool
1 sibling, 1 reply; 6+ messages in thread
From: Xi Ruoyao @ 2019-01-07 16:56 UTC (permalink / raw)
To: Felipe Gohring; +Cc: gcc-help
On 2019-01-07 11:14 -0500, Felipe Gohring wrote:
> Hello,
> recently, I have updated my GCC PowerPC port from 6.3 to 8.2
> As my architecture relies on SPE extension, I am using the SPE brench of
> GCC (powerpc-eabispe-*).
>
> 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.
Is there any difference w/o -g3? A increased size of debugging symbols
is not a bug and may provide better debug information for GDB. If the
object code itself bloats there may be a regression.
> 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?
It's likely these applications are invoking undefined behavior. There
may be a compiler bug though unlikely. Anyway you can do a bisect to see
which commit "broke" your code.
--
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC update increased the file size by 4x on PowerPC port
2019-01-07 16:56 ` Xi Ruoyao
@ 2019-01-07 16:59 ` Jonathan Wakely
0 siblings, 0 replies; 6+ messages in thread
From: Jonathan Wakely @ 2019-01-07 16:59 UTC (permalink / raw)
To: Felipe Gohring; +Cc: gcc-help
On Mon, 7 Jan 2019 at 16:56, Xi Ruoyao wrote:
>
> On 2019-01-07 11:14 -0500, Felipe Gohring wrote:
> > Hello,
> > recently, I have updated my GCC PowerPC port from 6.3 to 8.2
> > As my architecture relies on SPE extension, I am using the SPE brench of
> > GCC (powerpc-eabispe-*).
> >
> > 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.
>
> Is there any difference w/o -g3? A increased size of debugging symbols
> is not a bug and may provide better debug information for GDB. If the
> object code itself bloats there may be a regression.
And there's no memory overhead for debug info.
Compare the sizes of the files by using the 'size' command, not 'ls -l'.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC update increased the file size by 4x on PowerPC port
2019-01-07 16:12 GCC update increased the file size by 4x on PowerPC port Felipe Gohring
2019-01-07 16:56 ` Xi Ruoyao
@ 2019-01-07 17:23 ` Segher Boessenkool
2019-01-07 18:57 ` Felipe Gohring
1 sibling, 1 reply; 6+ messages in thread
From: Segher Boessenkool @ 2019-01-07 17:23 UTC (permalink / raw)
To: Felipe Gohring; +Cc: gcc-help
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.
And why are you using -mmfpgpr? That option doesn't do anything for anything
targetting SPE, but for some reason many people use it?
> 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.
Segher
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC update increased the file size by 4x on PowerPC port
2019-01-07 17:23 ` Segher Boessenkool
@ 2019-01-07 18:57 ` Felipe Gohring
2019-01-07 21:16 ` Felipe Gohring
0 siblings, 1 reply; 6+ messages in thread
From: Felipe Gohring @ 2019-01-07 18:57 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC update increased the file size by 4x on PowerPC port
2019-01-07 18:57 ` Felipe Gohring
@ 2019-01-07 21:16 ` Felipe Gohring
0 siblings, 0 replies; 6+ messages in thread
From: Felipe Gohring @ 2019-01-07 21:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-01-07 21:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-07 16:12 GCC update increased the file size by 4x on PowerPC port Felipe Gohring
2019-01-07 16:56 ` Xi Ruoyao
2019-01-07 16:59 ` Jonathan Wakely
2019-01-07 17:23 ` Segher Boessenkool
2019-01-07 18:57 ` Felipe Gohring
2019-01-07 21:16 ` Felipe Gohring
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).