[Intel-gfx] [PATCH 00/22] .rodata diet

David Weinehall david.weinehall at linux.intel.com
Tue Oct 11 12:17:14 UTC 2016


On Wed, Oct 05, 2016 at 01:33:27PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> 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.


Kind regards, David


More information about the Intel-gfx mailing list