Re: C++ in jemalloc

[I should have checked for 3 digit numerals in r<?> notation.]

On 2017-Oct-7, at 11:36 PM, Mark Millard <markmi at dsl-only.net> wrote:

> With a fresh day after sleep and some pondering
> I finally am thinking straight for where things
> are in files for C++ scratch register usage and
> such:
> 
> It is libgcc_s.so.1 that has all the extra use of
> scratch registers for C++ exception handling --and
> lots of other special stuff as well.
> 
> This note is just about overall counts of example
> usages in devel/powerpc64-gcc vs. clang processing
> the same libgcc_s source. it gives a clue about
> what coverage is going to be necessary.
> 
> 
> So the compare/contrast is of:
> (shown as seen in my context)
> 
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1
> vs.
> # dwarfdump -v -v -F /lib/libgcc_s.so.1
> 
> (That last being from a clang-based buildworld and the
> first being from a devel/powerpc64-xtoolchain-gcc
> material based buildworld.)
> 
> Using r2 through r6 as initial examples:
> 
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r[2-6]\>" | wc
>      43    2683   18432
> 
> vs.
> 
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "\<r[2-6]\>" | wc
>       0       0       0
> 
> That is an example of missing information from clang.
> 
> For powerpc64-gcc it is interesting that. . .
> 
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r2\>" | wc
>      23    2063   14308
> 
> but:
> 
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r3\>" | wc
>      27    2571   17800
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r4\>" | wc
>      27    2571   17800
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r5\>" | wc
>      27    2571   17800
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r6\>" | wc
>      27    2571   17800
> 
> and:
> 
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r7\>" | wc
>       0       0       0
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r8\>" | wc
>       0       0       0
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r9\>" | wc
>       0       0       0
> 
> Looks like r2 might sometimes be a scratch or otherwise
> special register during C++ exception handling --but not
> everyplace that r3-r6 are.
> 
> There are lots of other special r<?> names with numerals
> beyond that in the name r31 (powerpc64-gcc context):
> 
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r3[2-9]" | wc
>       0       0       0
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r4[0-9]" | wc
>      64    3248   22391
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r5[0-9]" | wc
>     124    3548   24183
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r6[0-9]" | wc
>     344    6978   49690
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r7[0-9]" | wc
>      46    2314   16176
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r8[0-9]" | wc
>       0       0       0
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r9[0-9]" | wc
>       0       0       0
> 
> Overall for > 31:
> 
> # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" | wc
>     505    7867   55379
> 
> 
> By contrast from clang for > 31:
> 
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" | wc
>     254    3110   21110
> 
> with the more detailed split out being:
> 
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r3[2-9]" | wc
>       0       0       0
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r4[0-9]" | wc
>      25     775    5190
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r5[0-9]" | wc
>      55     985    6265
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r6[0-9]" | wc
>     152    2396   17011
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r7[0-9]" | wc
>      24     828    5747
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r8[0-9]" | wc
>       0       0       0
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r9[0-9]" | wc
>      20     740    5135
> 
> WARNING:
> That last means that clang is using some r<?>'s that
> devel/powerpc64-gcc is not.
> 
> Is libgcc_s ready to deal with those extras that are
> in the 90s? Is this an ABI difference between clang
> (as configured) and powerpc64-gcc (as configured)?
> 
> Is there a problem based on powerpc64-gcc not generating
> examples of those 90s "extras"? Is this lack of support
> for some part of some ABI?

clang is also using r<?> with <?> in the 10x's:

# dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r10[0-9]" | wc
      45     315    2205
# dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r[0-9][0-9][0-9]" | wc
      45     315    2205


By contrast powerpc64-gcc is not:

# dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r[0-9][0-9][0-9]" | wc
       0       0       0


===
Mark Millard
markmi at dsl-only.net