Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?

[Gedare Bloom]

Joel, I think we're talking about removing inlining here for SPARC. -Gedare

On Wed, Mar 4, 2015 at 11:07 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> On 3/4/2015 9:52 AM, Gedare Bloom wrote:
>>
>> Because it has been that way since 1999?
>>
>> The only reason I can think would be to curtail register window
>> side-effects if there are any. I doubt there would be.
>
> I doubt there would be any side-effects either. It can't add to the
> maximum stack depth and it is unlikely to trigger a window overflow
> since we probably just returned from another subroutine call.
>
> One issue issue is coverage. When building for coverage,
> _Thread_Enable_dispatch
> should not be inlined. My quick grep shows 85 calls in cpukit. When not
> inlined,
> it is one branch to test. When inlined, we get 170 paths and our current
> tests
> don't test but 85 of those. We have no tests which make any API calls with
> a lock held.
>
> This may change with the lock work but it probably just moves branches
> around
> and we will end up with new issues for branch explosion due to inlining.
>
> --joel
>
>> Gedare
>>
>> On Wed, Mar 4, 2015 at 10:10 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>>>
>>> Hello,
>>>
>>> why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC? You can say a
>>> lot about SPARC, but not that function calls are slow.  Is it not better
>>> to
>>> reduce the code size and don't inline the _Thread_Enable_dispatch()?
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>> Phone   : +49 89 189 47 41-16
>>> Fax     : +49 89 189 47 41-09
>>> E-Mail  : sebastian.huber at embedded-brains.de
>>> PGP     : Public key available on request.
>>>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>