>From: Vineet Gupta <vgupta@xxxxxxxxxxxx> >Sent: Thursday, March 12, 2020 00:10 >To: Eugeniy Paltsev; linux-snps-arc@xxxxxxxxxxxxxxxxxxx >Cc: linux-kernel@xxxxxxxxxxxxxxx; 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 _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
