Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
Thread-Topic: [PATCH 2/2] ARC: don't align ret_from_exception function
Thread-Index: AQHV98HujcRrFCa3G0K90e5pOjYelKhDqFKAgAAx9muAAAkygIAADVOW
Date:   Wed, 11 Mar 2020 22:28:02 +0000
Message-ID: <BY5PR12MB403447EC9499A34209E12494DEFC0@BY5PR12MB4034.namprd12.prod.outlook.com>
References: <20200311162644.7667-1-Eugeniy.Paltsev@synopsys.com>
 <20200311162644.7667-2-Eugeniy.Paltsev@synopsys.com>
 <448ba208-56a5-d8b2-9675-7be03b872c23@synopsys.com>
 <BY5PR12MB40348292DA303489C1DA2B66DEFC0@BY5PR12MB4034.namprd12.prod.outlook.com>,<a6728afe-10e4-ce85-b133-17395ac99b86@synopsys.com>
In-Reply-To: <a6728afe-10e4-ce85-b133-17395ac99b86@synopsys.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: synopsys.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 201f0cbb-aa8f-462c-f081-08d7c60b7685
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 22:28:02.9991
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c33c9f88-1eb7-4099-9700-16013fd9e8aa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TiMv0aYj0X8RbIk3U82IuHlLGoVvDxdBwaNY8RRdcHk263WAT4sSfDycinD9nm45btMPUMBmTKVfr4SgiVidIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB3956
X-OriginatorOrg: synopsys.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>From: Vineet Gupta <vgupta@synopsys.com>=0A=
>Sent: Thursday, March 12, 2020 00:10=0A=
>To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org=0A=
>Cc: linux-kernel@vger.kernel.org; Alexey Brodkin=0A=
>Subject: Re: [PATCH 2/2] ARC: don't align ret_from_exception function=0A=
>=0A=
>On 3/11/20 1:58 PM, Eugeniy Paltsev wrote:=0A=
>>>=0A=
>>> I would like to keep it aligned.=0A=
>>>=0A=
>>> ARC700 definitely has penalty for unaligned branch targets, so it will =
definitely=0A=
>>> suffer there.=0A=
>>=0A=
>> Do you know some exact numbers? I'm not an expert in ARC700 (fortunately=
 =3D)=0A=
>=0A=
>I don't remember the exact numbers either.=0A=
>=0A=
>>> For HS, unaligned branch targets have no penalty (for the general case =
atleast),=0A=
>>> but if it does get unaligned, the entire entry prologue code will be - =
i.e. each=0A=
>>> one of the subsequent 130 or so instructions. That doesn't seem like a =
good idea=0A=
>>> in general to me.=0A=
>>=0A=
>> I really don't insist about applying this patch but I don't understand y=
our=0A=
>> argumentation about ARC HS like at all.=0A=
>=0A=
>I knew you would argue hence I already copy/pasted the start and end of th=
e=0A=
>epilogue already in my prev reply which you didn't care to read thru.=0A=
=0A=
Well, I beg to differ :)=0A=
=0A=
>If you start counting instructions from <ret_from_exception> all the way t=
o end of=0A=
><debug_marker_ds> there are over 130 instructions all of which can be rend=
ered=0A=
>unaligned by your patch. What is worse is that this would be unpredictable=
: the=0A=
>unaligned case will mostly NOT happen, but a new compiler or some subtle c=
ode=0A=
>change could causing potentially side-effects we won't even know where to =
look.=0A=
=0A=
I'm definitely missing something. Let's forget for a moment about our code=
=0A=
written in ASM and check the the binaries compiled from C sources.=0A=
The function is aligned by 4 bytes. However the function body contain the m=
ix of=0A=
16 bit, 32 bit, 48 bit and 64 bit instructions. So we have huge amount of=
=0A=
instructions with size > 16 bit which are aligned by 16 bit.=0A=
=0A=
I briefly checked our RPM but I don't see any note that it is OK to have=0A=
dozen of unaligned instructions but it is NOT OK to have a hundred of them.=
=0A=
=0A=
So, what are your concerns based on?=0A=
=0A=
>>> I faked it using a nop_s and the SYM_FUNC_START_NOALIGN( ) annotation a=
nd can see=0A=
>>> all instructions getting unaligned.=0A=
>>=0A=
>> What is the problem with it? It's totally valid and fine for ARC HS to h=
ave instructions=0A=
>> aligned by 2 byte. Or are you talking about ARC700 again?=0A=
>=0A=
>Yes I know that already. It is fine in general as I explained earlier, but=
 can=0A=
>potentially NOT when 130 instructions are unaligned.=0A=
>=0A=
>>> Before;=0A=
>>>=0A=
>>> 921238e4 <ret_from_exception>:=0A=
>>> 921238e4:    ld    r8,[sp,124]=0A=
>>> 921238e8:    bbit0.nt    r8,0x7,212=0A=
>>> ...=0A=
>>> 92123ac8:    rtie=0A=
>>> 92123acc <debug_marker_ds>:=0A=
>>> 92123acc:    ld    r2,[0x927d81d8]=0A=
>>> 92123ad4:    add    r2,r2,0x1=0A=
>>> 92123ad8:    st    r2,[0x927d81d8]=0A=
>>> 92123ae0:    bmskn    r11,r10,0xf=0A=
>>> 92123ae4:    sr    r11,[aux_irq_act]=0A=
>>> 92123ae8:    b    -140    ;92123a5c=0A=
>>>=0A=
>>> After:=0A=
>>>=0A=
>>> 9212393c:    nop_s=0A=
>>> 9212393e <ret_from_exception>:=0A=
>>> 9212393e:    ld    r8,[sp,124]=0A=
>>> 92123942:    bbit0.nt    r8,0x7,214=0A=
>>> ...=0A=
>>> 92123b22:    rtie=0A=
>>> 92123b26 <debug_marker_ds>:=0A=
>>> 92123b26:    ld    r2,[0x927d81d8]=0A=
>>> 92123b2e:    add    r2,r2,0x1=0A=
>>> 92123b32:    st    r2,[0x927d81d8]=0A=
>>> 92123b3a:    bmskn    r11,r10,0xf=0A=
>>> 92123b3e:    sr    r11,[aux_irq_act]=0A=
>>> 92123b42:    b    -138    ;92123ab6 <debug_marker_syscall>=0A=
>>> 92123b46:    nop_s=