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
