lkml.org 
[lkml]   [2020]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2/2] ARC: don't align ret_from_exception function
Date
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.

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 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
\
 
 \ /
  Last update: 2020-03-11 22:14    [W:0.077 / U:76.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site