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

[Tvrtko Ursulin]

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 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.
>

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