From: Vineet Gupta <vgupta@kernel.org>
To: Mike Rapoport <rppt@kernel.org>, Vineet Gupta <vgupta@kernel.org>
Cc: linux-snps-arc@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Anshuman Khandual <anshuman.khandual@arm.com>
Subject: Re: [PATCH 06/18] ARC: mm: Enable STRICT_MM_TYPECHECKS
Date: Wed, 11 Aug 2021 12:01:26 -0700 [thread overview]
Message-ID: <ecbba2ab-6d05-cbbf-9545-01a62c722e5c@kernel.org> (raw)
In-Reply-To: <YRO8xUlAtMeJnDbe@kernel.org>
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.
next prev parent reply other threads:[~2021-08-11 19:01 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 0:42 [PATCH 00/18] ARC mm updates to support 3 or 4 levels of paging Vineet Gupta
2021-08-11 0:42 ` [PATCH 01/18] ARC: mm: simplify mmu scratch register assingment to mmu needs Vineet Gupta
2021-08-11 0:42 ` [PATCH 02/18] ARC: mm: remove tlb paranoid code Vineet Gupta
2021-08-11 0:42 ` [PATCH 03/18] ARC: mm: move mmu/cache externs out to setup.h Vineet Gupta
2021-08-11 5:10 ` Mike Rapoport
2021-08-11 18:46 ` Vineet Gupta
2021-08-11 0:42 ` [PATCH 04/18] ARC: mm: remove pgd_offset_fast Vineet Gupta
2021-08-11 5:12 ` Mike Rapoport
2021-08-11 18:54 ` Vineet Gupta
2021-08-11 0:42 ` [PATCH 05/18] ARC: mm: Fixes to allow STRICT_MM_TYPECHECKS Vineet Gupta
2021-08-11 0:42 ` [PATCH 06/18] ARC: mm: Enable STRICT_MM_TYPECHECKS Vineet Gupta
2021-08-11 12:04 ` Mike Rapoport
2021-08-11 19:01 ` Vineet Gupta [this message]
2021-08-11 0:42 ` [PATCH 07/18] ARC: ioremap: use more commonly used PAGE_KERNEL based uncached flag Vineet Gupta
2021-08-11 5:18 ` Mike Rapoport
2021-08-11 18:58 ` Vineet Gupta
2021-08-11 0:42 ` [PATCH 08/18] ARC: mm: pmd_populate* to use the canonical set_pmd (and drop pmd_set) Vineet Gupta
2021-08-11 0:42 ` [PATCH 09/18] ARC: mm: non-functional code cleanup ahead of 3 levels Vineet Gupta
2021-08-11 12:31 ` Mike Rapoport
2021-08-12 1:37 ` Vineet Gupta
2021-08-12 6:18 ` Mike Rapoport
2021-08-12 18:58 ` Vineet Gupta
2021-08-11 0:42 ` [PATCH 10/18] ARC: mm: move MMU specific bits out of ASID allocator Vineet Gupta
2021-08-11 0:42 ` [PATCH 11/18] ARC: mm: move MMU specific bits out of entry code Vineet Gupta
2021-08-11 12:15 ` Mike Rapoport
2021-08-11 19:30 ` Vineet Gupta
2021-08-11 0:42 ` [PATCH 12/18] ARC: mm: disintegrate mmu.h (arcv2 bits out) Vineet Gupta
2021-08-11 0:42 ` [PATCH 13/18] ARC: mm: disintegrate pgtable.h into levels and flags Vineet Gupta
2021-08-11 0:42 ` [PATCH 14/18] ARC: mm: hack to allow 2 level build with 4 level code Vineet Gupta
2021-08-11 0:42 ` [PATCH 15/18] ARC: mm: support 3 levels of page tables Vineet Gupta
2021-08-11 12:24 ` Mike Rapoport
2021-08-11 22:15 ` Vineet Gupta
2021-08-11 0:42 ` [PATCH 16/18] ARC: mm: support 4 " Vineet Gupta
2021-08-11 12:28 ` Mike Rapoport
2021-08-11 22:17 ` Vineet Gupta
2021-08-11 0:42 ` [PATCH 17/18] ARC: mm: vmalloc sync from kernel to user table to update PMD Vineet Gupta
2021-08-11 0:42 ` [PATCH 18/18] ARC: mm: introduce _PAGE_TABLE to explicitly link pgd,pud,pmd entries Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ecbba2ab-6d05-cbbf-9545-01a62c722e5c@kernel.org \
--to=vgupta@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).