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.ursu...@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.
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
