[Bug c/51622] New: GCC generates bad code that generate big executable sizes when using _Decimal*

[Bug c/51622] New: GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

             Bug #: 51622
           Summary: GCC generates bad code that generate big executable
                    sizes when using _Decimal*
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mingodad@gmail.com


Created attachment 26140
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26140
Program and a batch file to show how strange is gcc code generation when using
_Decimal*

The main point here is to demonstrate that gcc is capable to generate good code
size when using _Decimal* but for some reason it get lost with some code
combinations and generates very big executables unnecessarily making a bad
balance between functionality/size.

Here is a program that demonstrate that gcc is generating bad code resulting in
big executables when using _Decimal*.

There is a main.c with several operations on _Decimal64, few on _Decimal128
with some combination of the code (with all operations) the final executable
file is 8KB but with a different combination (again with all operations) the
executable is 2.206KB or 2.2MB. This last one is very strange because the
diference betwen then is calling a printf to print several existing _Decimal64
variable (the biggest 2.2MB) and calling a printf to print only one existing
_Decimal64 variable ((double)discount_over_sales the smallest 8KB but if we try
to any other existing variables it goes to 2.2MB).

gcc -s -O2 -DWITH_TMP main.c -o smallest.exe -> 8KB
gcc -s -O2 -DWITH_ONE_BIG_PRINTF -DWITH_TMP main.c -o strange-big-size-jump.exe
-> 2.206KB or 2.2MB
gcc -s -O2 main.c -o good1.exe -> 8KB
gcc -s -O2 -DWITH_DEC128 -DWITH_ISNAN -DWITH_MPRINTF main.c printf.c -o
biggest.exe -> 2.444KB or 2.4MB
gcc -s -O2 -DWITH_MPRINTF main.c printf.c -o optimus.exe -> 154KB
gcc -s -O2 -DWITH_DEC128 -DWITH_MPRINTF main.c printf.c -o good2.exe -> 367KB

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

--- Comment #1 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-19 12:17:28 UTC ---
If code generation is solved probably we can have better results with the
following:

lua 5.1.4 with double -> 150KB
lua 5.1.4 with _Decimal64 -> 2.4MB *with ***bad code generation
lua 5.1.4 with _Decimal64 -> 160KB *with hopefully ***good code generation

sqlite3 with double -> 500KB
sqlite3 with _Decimal64 -> 3MB *with ***bad code generation
sqlite3 with _Decimal64 -> 530KB *with hopefully ***good code generation

The same proportion probably will apply to any other program using _Decimal*
wich will make using _Decimal* a very interesting option.

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011-12-19
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-19 12:25:16 UTC ---
Which architecture are you compiling for?

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 12:33:42 UTC ---
There are already some partial explanations in bug 51364

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

--- Comment #4 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-19 14:30:26 UTC ---
Created attachment 26143
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26143
Another program to demonstrate gcc bad code generation

On the previous example program my conclusions doesn't make much senes because
gcc was optimizing the code and removing all code without side effects or in
other words the small executables end up almost empty (good job of gcc).

This new program contains the previous and add a program main2.c that when
compiled without any optimization to not ending empty demonstrate the problem.

Doing almost any arithmetic operations with _Decimal64 without mix with
_Decimal128 or with automatic convertion to double gives an executable of
270KB.

If we mix with _Decimal128 gives executable of 473KB.

Now if we add a call to isnan the executable goes to 2.374KB, almost 2MB
monolithic code only to isnan or even if we use ceil or floor or any other math
functions, it seems too much for only a small adittion.

And if I use a home made function to convert from _Decima64 to double there is
now increase on executable size, but if using automatic generated conversion
from gcc it grows to 2.374KB.

I think that there is a problem with the way the _Decimal* library is coded,
maybe all in one single code file instead of small ones with only one function,
because with one function per code file adding a new function call will not
link a lot of unnecessary code.

gcc main2.c -o no-opt-small.exe -> 270KB
gcc -DWITH_GCC_DEC2DBL main2.c -o no-opt-gcc-dec2dbl.exe -> 2.374KB
gcc -DWITH_MIX128 main2.c -o no-opt-mix128.exe -> 473KB
gcc -DWITH_ISNAN main2.c -o no-opt-isnan.exe -> 2.374KB
gcc -DWITH_MIX128 -DWITH_ISNAN main2.c -o no-opt-isnan-mix128.exe -> 2.578KB

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

--- Comment #5 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-19 14:34:11 UTC ---
(In reply to comment #2)
> Which architecture are you compiling for?

gcc mingw32 4.6.1 32bits

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

--- Comment #6 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-19 14:40:45 UTC ---
Rewrite expected executable sizes with a realistic better code generation by
gcc.

If code generation is solved probably we can have better results with the
following:

lua 5.1.4 with double -> 150KB
lua 5.1.4 with _Decimal64 -> 2.4MB *with ***bad code generation
lua 5.1.4 with _Decimal64 -> 370KB *with hopefully ***good code generation

sqlite3 with double -> 500KB
sqlite3 with _Decimal64 -> 3MB *with ***bad code generation
sqlite3 with _Decimal64 -> 930KB *with hopefully ***good code generation

The same proportion probably will apply to any other program using _Decimal*
wich will make using _Decimal* a very interesting option.

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-19 14:59:44 UTC ---
Seems to me that you don't seem to understand what it means that the dfp
support bits from libgcc.a are statically linked into your application.  There
is no bad code generation, the only problem is that libbid has lots of small
*.o files, then about 7 mid size *.o files (~ 16KB to ~ 64KB of code, almost no
.rodata) and then a single huge one - bid_binarydecimal.o - which, while it
contains a tiny bit above 64KB of code, contains additionally 2MB of read-only
data in various tables, and unfortunately this huge 6MB of source file is used
by many of the routines.  The reason why the decimal stuff isn't in libgcc_s
(i.e. shared library) is because _Decimal* support is huge amount of code for
something used extremely rarely.  It could be either built into a separate
shared library and ask people to add that library in, or perhaps this single
huge source file could be split into several smaller ones, so you get only the
code you really need to handle the operations you are using, or it could be
built with -ffunction-sections -fdata-sections and allow people to use
-Wl,--gc-sections to garbage collect it.

OT, your comments about using _Decimal64 as an interesting option to double are
very weird, the two types are completely different, have different purpose,
_Decimal* is (except for some PowerPC and S390* chips) completely software
emulated type and thus very slow, double has on the other side usually very
fast operations on it implemented in hw.

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

--- Comment #8 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-19 21:19:40 UTC ---
Here is my contribution of bid_decimal.c splitted into several parts to allow
better link size and easy edit/view.

http://code.google.com/p/luafltk/downloads/detail?name=bid_decimal-splited.zip&can=2&q=

19/12/2011  21:01            32,103 bid_bd_breakpoints_bid32.c
19/12/2011  21:02           130,885 bid_bd_breakpoints_bid64.c
19/12/2011  21:02           491,874 bid_bd_breakpoints_binary128.c
19/12/2011  21:03             6,826 bid_bd_breakpoints_binary32.c
19/12/2011  21:03            34,713 bid_bd_breakpoints_binary64.c
19/12/2011  21:02           481,006 bid_bd_breakpoints_binary80.c
19/12/2011  21:00             2,590 bid_bd_coefflimits_bid128.c
19/12/2011  21:00             1,823 bid_bd_coefflimits_bid32.c
19/12/2011  21:00             1,970 bid_bd_coefflimits_bid64.c
19/12/2011  21:01             5,242 bid_bd_exponents_bid32.c
19/12/2011  21:02            18,812 bid_bd_exponents_bid64.c
19/12/2011  21:01            86,996 bid_bd_exponents_binary128.c
19/12/2011  21:03             1,805 bid_bd_exponents_binary32.c
19/12/2011  21:03             5,991 bid_bd_exponents_binary64.c
19/12/2011  21:02            86,885 bid_bd_exponents_binary80.c
19/12/2011  20:59             2,004 bid_bd_innertable_exp.c
19/12/2011  20:59            11,496 bid_bd_innertable_sig.c
19/12/2011  21:01            54,704 bid_bd_multipliers1_bid32.c
19/12/2011  21:00           255,563 bid_bd_multipliers1_bid64.c
19/12/2011  21:01         1,023,169 bid_bd_multipliers1_binary128.c
19/12/2011  21:03            10,692 bid_bd_multipliers1_binary32.c
19/12/2011  21:03            66,823 bid_bd_multipliers1_binary64.c
19/12/2011  21:02         1,021,616 bid_bd_multipliers1_binary80.c
19/12/2011  21:00            55,951 bid_bd_multipliers2_bid32.c
19/12/2011  21:00           257,033 bid_bd_multipliers2_bid64.c
19/12/2011  21:01         1,023,037 bid_bd_multipliers2_binary128.c
19/12/2011  21:03            10,697 bid_bd_multipliers2_binary32.c
19/12/2011  21:03            66,861 bid_bd_multipliers2_binary64.c
19/12/2011  21:02         1,021,488 bid_bd_multipliers2_binary80.c
19/12/2011  21:01             1,706 bid_bd_outertable_exp.c
19/12/2011  21:02             9,280 bid_bd_outertable_sig.c
19/12/2011  21:08             2,602 bid_bd_power_five.c
19/12/2011  21:08             2,334 bid_bd_roundbound_128.c
19/12/2011  21:11            23,033 bid_bd_to_bid128.c
19/12/2011  21:11            21,887 bid_bd_to_bid32.c
19/12/2011  21:12            22,605 bid_bd_to_bid64.c
19/12/2011  21:12            13,901 bid_bd_to_binay128.c
19/12/2011  21:12            12,875 bid_bd_to_binay32.c
19/12/2011  21:13            12,808 bid_bd_to_binay64.c
19/12/2011  21:13            12,934 bid_bd_to_binay80.c
19/12/2011  21:14            37,312 bid_binarydecimal.h


dfp-filenames =
ifneq ($(D32PBIT)$(D64PBIT)$(D128PBIT),)
ifeq ($(enable_decimal_float),bid)
dfp-filenames += bid_decimal_globals bid_decimal_data \
++++++++++++++++
         bid_bd_to_bid32 bid_bd_to_bid64 bid_bd_to_bid128 \
         bid_bd_to_binary32 bid_bd_to_binary64 \
         bid_bd_to_binary80 bid_bd_to_binary128 \
++++++++++++++++
         bid_convert_data \
         _isinfd32 _isinfd64 _isinfd128 bid64_noncomp \
         bid128_noncomp bid128_fma bid_round bid_from_int \
         bid64_add bid128_add bid64_div bid128_div \
         bid64_mul bid128_mul bid64_compare bid128_compare \
         bid128 bid32_to_bid64 bid32_to_bid128 bid64_to_bid128 \
         bid64_to_int32 bid64_to_int64 \
         bid64_to_uint32 bid64_to_uint64 \
         bid128_to_int32 bid128_to_int64 \
         bid128_to_uint32 bid128_to_uint64
else
dfp-filenames += decContext decNumber decExcept decRound decLibrary decDouble
decPacked decQuad decSingle
endif
endif

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

--- Comment #9 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-20 17:30:55 UTC ---
Some mistakes corrected and it was compiled with mingw 4.6.1 and wotk as
expected.

The results:
lua 5.1.4 with _Decimal64 from 2.4MB to 681KB
sqlite3 with _Decimal64 from 3MB to 1.239KB

http://code.google.com/p/luafltk/downloads/detail?name=bid_decimal-splited-2.zip&can=2&q=

dfp-filenames =
ifneq ($(D32PBIT)$(D64PBIT)$(D128PBIT),)
ifeq ($(enable_decimal_float),bid)
dfp-filenames += bid_decimal_globals bid_decimal_data \
++++++++++++++++
         bid_bd_to_bid32 bid_bd_to_bid64 bid_bd_to_bid128 \
         bid_bd_to_binary32 bid_bd_to_binary64 \
         bid_bd_to_binary80 bid_bd_to_binary128 \
         bid_bd_power_five bid_bd_roundbound_128 \
++++++++++++++++
         bid_convert_data \
         _isinfd32 _isinfd64 _isinfd128 bid64_noncomp \
         bid128_noncomp bid128_fma bid_round bid_from_int \
         bid64_add bid128_add bid64_div bid128_div \
         bid64_mul bid128_mul bid64_compare bid128_compare \
         bid128 bid32_to_bid64 bid32_to_bid128 bid64_to_bid128 \
         bid64_to_int32 bid64_to_int64 \
         bid64_to_uint32 bid64_to_uint64 \
         bid128_to_int32 bid128_to_int64 \
         bid128_to_uint32 bid128_to_uint64
else
dfp-filenames += decContext decNumber decExcept decRound decLibrary decDouble
decPacked decQuad decSingle
endif
endif

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

--- Comment #10 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-21 10:36:45 UTC ---
Now looking on the net I found that libbid history and could see that the
actual one monolithic bid_decimalbinary file is a recent creation before it was
splited over several files, I don't think that this is a good move, it's hard
to edit, it links unnecessary code to all applications that do no use all
_Decimal sizes, ...

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
As mentioned this is because decimal floating point is all soft implementation
and that brings in a lot of code.