search

itanium-cxx-abi / cxx-abi

C++ ABI Summary
504 stars 94 forks source link

Add mangling for fixed point types proposed in N1169. #161

Closed PiJoules closed 1 year ago

PiJoules commented 1 year ago

Not sure how to "reference" issues with PRs, but this is for issue https://github.com/itanium-cxx-abi/cxx-abi/issues/56

PiJoules commented 1 year ago

We have an active PR in #159 to make certain extended types substitutable. Should these be substitution candidates if the same type is used in multiple places?

I asked around and we unfortunately don't know how common it would be to have mangled signatures with fixed-point types in them in places we might intend to use them. Sorry for the incomplete answer. Although given that the largest mangling for a fixed-point type is 5 characters and substitutions should be less than that, we still think having a sub should provide savings.

rjmccall commented 1 year ago

Okay. The abstract guideline here is that adding substitutions does have a cost: in longer symbols, it can actually increase overall symbol size by filling the substitution table with a lot of extra types, making later substitutions larger. I would say the line is around 4 bytes — a 3-byte mangling is probably not worth substituting, but a 5-byte mangling probably is.

Applying that to this would make only the saturating types candidates. But treating different fixed-point types differently might be annoying to implement, and it's probably not a big deal either way.

Given that, do you have a strong opinion?

PiJoules commented 1 year ago

Okay. The abstract guideline here is that adding substitutions does have a cost: in longer symbols, it can actually increase overall symbol size by filling the substitution table with a lot of extra types, making later substitutions larger. I would say the line is around 4 bytes — a 3-byte mangling is probably not worth substituting, but a 5-byte mangling probably is.

Applying that to this would make only the saturating types candidates. But treating different fixed-point types differently might be annoying to implement, and it's probably not a big deal either way.

Given that, do you have a strong opinion?

Yeah in that case I'd probably want to aim for consistency and would lean towards not making any of them candidates.

PiJoules commented 1 year ago

ping for any more comments on this

zygoloid commented 1 year ago

Looks good to me.

rjmccall commented 1 year ago

Alright, I think this has been open for long enough.