LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Alexey Brodkin" <Alexey.Brodkin@synopsys.com>
Subject: Re: [PATCH 2/2] ARC: don't align ret_from_exception function
Date: Wed, 11 Mar 2020 22:28:02 +0000 [thread overview]
Message-ID: <BY5PR12MB403447EC9499A34209E12494DEFC0@BY5PR12MB4034.namprd12.prod.outlook.com> (raw)
In-Reply-To: <a6728afe-10e4-ce85-b133-17395ac99b86@synopsys.com>
>From: Vineet Gupta <vgupta@synopsys.com>
>Sent: Thursday, March 12, 2020 00:10
>To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org
>Cc: linux-kernel@vger.kernel.org; Alexey Brodkin
>Subject: Re: [PATCH 2/2] ARC: don't align ret_from_exception function
>
>On 3/11/20 1:58 PM, Eugeniy Paltsev wrote:
>>>
>>> I would like to keep it aligned.
>>>
>>> ARC700 definitely has penalty for unaligned branch targets, so it will definitely
>>> suffer there.
>>
>> Do you know some exact numbers? I'm not an expert in ARC700 (fortunately =)
>
>I don't remember the exact numbers either.
>
>>> For HS, unaligned branch targets have no penalty (for the general case atleast),
>>> but if it does get unaligned, the entire entry prologue code will be - i.e. each
>>> one of the subsequent 130 or so instructions. That doesn't seem like a good idea
>>> in general to me.
>>
>> I really don't insist about applying this patch but I don't understand your
>> argumentation about ARC HS like at all.
>
>I knew you would argue hence I already copy/pasted the start and end of the
>epilogue already in my prev reply which you didn't care to read thru.
Well, I beg to differ :)
>If you start counting instructions from <ret_from_exception> all the way to end of
><debug_marker_ds> there are over 130 instructions all of which can be rendered
>unaligned by your patch. What is worse is that this would be unpredictable: the
>unaligned case will mostly NOT happen, but a new compiler or some subtle code
>change could causing potentially side-effects we won't even know where to look.
I'm definitely missing something. Let's forget for a moment about our code
written in ASM and check the the binaries compiled from C sources.
The function is aligned by 4 bytes. However the function body contain the mix of
16 bit, 32 bit, 48 bit and 64 bit instructions. So we have huge amount of
instructions with size > 16 bit which are aligned by 16 bit.
I briefly checked our RPM but I don't see any note that it is OK to have
dozen of unaligned instructions but it is NOT OK to have a hundred of them.
So, what are your concerns based on?
>>> I faked it using a nop_s and the SYM_FUNC_START_NOALIGN( ) annotation and can see
>>> all instructions getting unaligned.
>>
>> What is the problem with it? It's totally valid and fine for ARC HS to have instructions
>> aligned by 2 byte. Or are you talking about ARC700 again?
>
>Yes I know that already. It is fine in general as I explained earlier, but can
>potentially NOT when 130 instructions are unaligned.
>
>>> Before;
>>>
>>> 921238e4 <ret_from_exception>:
>>> 921238e4: ld r8,[sp,124]
>>> 921238e8: bbit0.nt r8,0x7,212
>>> ...
>>> 92123ac8: rtie
>>> 92123acc <debug_marker_ds>:
>>> 92123acc: ld r2,[0x927d81d8]
>>> 92123ad4: add r2,r2,0x1
>>> 92123ad8: st r2,[0x927d81d8]
>>> 92123ae0: bmskn r11,r10,0xf
>>> 92123ae4: sr r11,[aux_irq_act]
>>> 92123ae8: b -140 ;92123a5c
>>>
>>> After:
>>>
>>> 9212393c: nop_s
>>> 9212393e <ret_from_exception>:
>>> 9212393e: ld r8,[sp,124]
>>> 92123942: bbit0.nt r8,0x7,214
>>> ...
>>> 92123b22: rtie
>>> 92123b26 <debug_marker_ds>:
>>> 92123b26: ld r2,[0x927d81d8]
>>> 92123b2e: add r2,r2,0x1
>>> 92123b32: st r2,[0x927d81d8]
>>> 92123b3a: bmskn r11,r10,0xf
>>> 92123b3e: sr r11,[aux_irq_act]
>>> 92123b42: b -138 ;92123ab6 <debug_marker_syscall>
>>> 92123b46: nop_s
next prev parent reply other threads:[~2020-03-11 22:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 16:26 [PATCH 1/2] ARC: define __ALIGN_STR and __ALIGN symbols for ARC Eugeniy Paltsev
2020-03-11 16:26 ` [PATCH 2/2] ARC: don't align ret_from_exception function Eugeniy Paltsev
2020-03-11 17:38 ` Vineet Gupta
2020-03-11 20:58 ` Eugeniy Paltsev
2020-03-11 21:10 ` Vineet Gupta
2020-03-11 22:28 ` Eugeniy Paltsev [this message]
2020-03-11 16:35 ` [PATCH 1/2] ARC: define __ALIGN_STR and __ALIGN symbols for ARC 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=BY5PR12MB403447EC9499A34209E12494DEFC0@BY5PR12MB4034.namprd12.prod.outlook.com \
--to=eugeniy.paltsev@synopsys.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--subject='Re: [PATCH 2/2] ARC: don'\''t align ret_from_exception function' \
/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
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).