CCS/TMS320F28374D: Inlining issue using " big" code

Inlining is a tricky subject. The optimizer puts limits on the size of a function that it will inline so that you don't have the problem of the compiler taking an exponentially long time to compile.

Generally you can't inline interrupt handler functions at all; are you really trying to inline the handler itself, or a function that the handler calls?

Have you declared the function you want to inline as "inline"?

See also:

processors.wiki.ti.com/.../C++_Inlining_Issues

Archaeologist thank you for your answer.

I'm trying to inline several functions  that the handler calls. All the functions I would like to inline are declared inline of course. I know also that exist the PRAGMA #ALWAYS_INLINE(function) which works perfect.

The problem was not related to the length of the functions I have to inline, rather to the length of the code I have in the interrupt handler: if the number of code line exceed, at certain point the functions, which before were inlined, then are not inlined anymore: it seems that there is a code line limit for a file: over this limit the inline is not ensured anymore. I'm talking about line code limit, because a simple assigment like a = 0; make the difference.

Carlo reported the problem for me, he has also two different project presenting the problem.

Do you know if the compiler has a code line limit to decide if inlining or not:?

Thank you again 

If you would like advice specific to your situation, then please send us some source code as detailed in the article How to Submit a Compiler Test Case.  In addition, please tell us the names of some of the functions which you expect to inline, but don't.

Thanks and regards,

-George

Hi George , 

please link you suggested is  down ,  coudl you cjheck or send me procedure offline ?

it is urgent 

thank you 

bye

Carlo

The link is not down, it was just wrong.  I don't know how that happened.  I have since edited that post and fixed it.  All the same, here is the full address:  

Thanks and regards,

-George

Thank you for submitting a test case.  This one was trickier than most.  I can reproduce the problem.  It is not a bug in the compiler.  That is, the code generated is correct.  But it is a performance problem.  The generated code runs slower than desired.  I filed CODEGEN-3594 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

Thanks and regards,

-George

I was wrong, and I was right. The test case is encountering one of those arbitrary limits, and it's the size of the caller that matters. There is an arbitrary limit of 700 basic blocks -- inlining will not create a function larger than that.

It is reasonable to assert that C2000 inlining should not use that particular limit, as it's an accidental effect of some refactoring, and in fact releases 6.0.x and earlier did not have it. That's probably the solution I will choose.

(How did I choose 700? Over a collection of tests and applications, I varied some inlining parameters and plotted compilation time and space. 700 is about where some of them started to become seriously super-linear. But one can certainly argue that the limit should be more tailored by target.)

Good morning George,
first of all thank you for your time. I suspected somenthing similar as the more the length of the code increase, the less inline functions were actually inlined.

Well George, at list we have 2 solutions:
1) we carfull to write very long functions, and if this would be the case, because is required by our application, then we can choose an erlier compiler version
2) Use the pragma ALWAYS_INLINE(), which works, even in the case of long code.

Just a final question: do you think the limit will be removed in the next compiler version, or will be manteined?

Thank you again,
Regards,
Andrea Marcianesi

I see no obstacle to removing it in the 17.9.0 release. I doubt we'd remove it in the 6.4.x series, because we are no longer supporting that branch, but that's a call for my supervisor (who's away for another week or so).

But: there's no guarantee that the compiler will continue to inline functions in the same way forever. The C2000 compiler currently inlines all calls to a function, or none (aside from problems like this one), but our ARM compiler inlines only the calls that it estimates will have the most benefit. If we change the C2000 compiler to use that scheme, then the only way to ensure the behavior you desire will be the always-inline pragma.