[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ecbba2ab-6d05-cbbf-9545-01a62c722e5c@kernel.org>
Date: Wed, 11 Aug 2021 12:01:26 -0700
From: Vineet Gupta <vgupta@...nel.org>
To: Mike Rapoport <rppt@...nel.org>, Vineet Gupta <vgupta@...nel.org>
Cc: linux-snps-arc@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Anshuman Khandual <anshuman.khandual@....com>
Subject: Re: [PATCH 06/18] ARC: mm: Enable STRICT_MM_TYPECHECKS
On 8/11/21 5:04 AM, Mike Rapoport wrote:
> On Tue, Aug 10, 2021 at 05:42:46PM -0700, Vineet Gupta wrote:
>> In the past I've refrained from doing this (atleast 2 times) due to the
> ^ at least
>
>> slight code bloat due to ABI implications of pte_t etc becoming sttuct
> ^ struct
>> Per ARC ABI, functions return struct via memory and not through register
>> r0, even if the struct would fits in register(s)
> ^ fit
Fixed.
>> - caller allocates space on stack and passes the address as first arg
>> (r0), shifting rest of args by one
>>
>> - callee creates return struct in memory (referenced via r0)
>>
>> This time around the code actually shrunk slightly (due to subtle
>> inlining heuristic effects), but still slightly inefficient due to
>> return values passed through memory. That however seems like a small
> Out of curiosity, is this actually measurable on real world applications?
Not really, but they look hideous to an objdump hunkie like me (who
treats waste of electrons like wasting food) and wondering what piece of
art your compiler is spitting out ;-) only to realize that is source
code induced.
Powered by blists - more mailing lists