Re: [PATCH 00/22] .rodata diet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 11/10/2016 13:17, David Weinehall wrote:
On Wed, Oct 05, 2016 at 01:33:27PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>

Dynamic typing in __I915__ (INTEL_INFO) has and unfortuante consequence that
for every time it is called under a WARN it generates a very verbose string
placed into the appropriate .rodata section.

Each instance of that can can several hundred bytes to the binary. One example
of such strings found in the binary, not word-wrapped is:

WARN_ON(!((&({ struct drm_i915_private *__p; if (__builtin_types_compatible_p(typeof(*dev_priv), struct drm_i915_private)) __p = (struct drm_i915_private *)dev_priv; else if (__builtin_types_compatible_p(typeof(*dev_priv), struct drm_device)) __p = to_i915((struct drm_device *)dev_priv); else do { bool __cond = !(!(1)); extern void __compiletime_assert_1912(void) __attribute__((error("BUILD_BUG failed"))); if (__cond) __compiletime_assert_1912(); do { } while (0); } while (0); __p; })->info)->has_ddi) && (control & (0xffff << 16)) != (0xabcd << 16))

If we gradually remove dynamic typing abilities from individual macros we can
start bringing the size of the binary down.

For example after this series:

    text    data     bss     dec     hex filename
1067727   23256     576 1091559  10a7e7 i915.ko.nightly
1038202   23256     576 1062034  103492 i915.ko.diet

Which is a ~29KiB saving.

This is disruptive of course, but perhaps it is time to bite the bullet since we
now have a situation that even new platforms like Kabylake are adding code which
uses the wrong thing in those macros (dev instead of dev_priv).

The way I have done it here makes it impossible to use the converted macros in
a wrong way going forward.
Amen, hallelujah!

I'll happily review the entire series (I've done this same job once
already). Is this still the latest version, or do you have an update?

I've also got a patch series for the remaining INTEL_INFO() fixes;
once your patches are merged I can submit those.


I have an updated version with some review comments incorporated and from which I have split out the unrelated const table shrinks.

Good news is that now both Daniel and Jani are in favour so we just need to agree on merging dynamics.

I will send the updated series out today. Thanks for reviewing!

Regards,

Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux