Removing internal_function

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing internal_function

Florian Weimer-5
Should we remove internal_function?  It's only used on i386 and causes
portability hazards due to the i386-specific build failures it can
introduce.  (Unlike attribute_hidden and most other function attributes,
internal_function has to be repeated on both declaration and definition.)

internal_function specifies an alternative calling convention.  For
static functions, GCC has been doing similar optimizations for a long
time.  I assume internal_function could disable those optimizations by
explicitly specifying a different (less optimal) calling convention.

The original intent was that internal_function would not be used across
DSO boundaries (because the non-ABI calling convention), but we no
longer stick to that.

Disabling internal_function appears to increase the text size of
libc.so.6 by about 8K, or 0.45%.  Considering the relative importance of
the i386 target today, I think this is a reasonable trade-off for the
avoidance of spurious build failures.

Comments?

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Removing internal_function

Siddhesh Poyarekar-8
On Monday 03 April 2017 08:36 PM, Florian Weimer wrote:
> internal_function specifies an alternative calling convention.  For
> static functions, GCC has been doing similar optimizations for a long
> time.  I assume internal_function could disable those optimizations by
> explicitly specifying a different (less optimal) calling convention.

A good place to start may be to get rid of it in non i686 code (a quick
grep found instances in arm code for example) and for static functions.
The non-i686 code changes should ideally be obvious, since they should
result in no change in the generated code.

Siddhesh