• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 792 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6678 MUST_ITERATE multiple question.

C. García
Intellectual 830 points

Hi,

I'm using MUST_ITERATE(8,131,8)  and in this case, the max divided by the multiple is not an integer result.

1 - Please, could somebody tell me what the compiler optimization will do in this case?

2 - Please, could somebody tell me if this case will generate any problem and how to solve it if I need to use MUST_ITERATE as I wrote above?

Thanks in advance.

C. Garcia

 

 

  • 0
    TI__Guru**** 253380 points

    I'm not sure what the compiler will do.  But I do want to point that #pragma MUST_ITERATE is inconsistent.  The parameters are #pragma MUST_ITERATE(minimum, maximum, multiple).  If you specify multiple, then both minimum and maximum must be even multiples of that value.  In you case, 131 is not an even multiple of 8.

    On a slightly related note ...  You can omit parameters. #pragma MUST_ITERATE(8,,8) says a loop runs at least 8 times, and always a multiple of 8 times.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 830 points

    Hi George,

    I have another question,

    Suppose that I use #pragma MUST_ITERATE(8, 128, 8) as TI recomend.

    When I use the for loop, my upper limit is a variable and sometimes I can receive 127 instead of 128.

    Please, could you tell me if in this case there will be a software bug or any software error?

    Thanks.

    C. Garcia

     

     

  • 0 in reply to C. García
    TI__Expert 4930 points

    If the upper limit can sometimes be 127, and you're told the compiler that all trip counts will be a multiple of 8, then you've lied to the compiler.  The compiler may do something like unroll the loop 2X or 4X or 8X, which will not operate correctly with a trip count of 127.

    But it may not do it today.  It may do it when you change code nearby that makes the unrolling more profitable.  It may do it when a call within the function is changed to be inlineable.  It may do it with a future compiler version.  Maybe it unrolls 2X now and happens to work, and unrolls 8X in the future and the error becomes apparent.  Maybe a trip count of 127 is so rare that the problem doesn't appear for five years.

    The point of these annotations is not to manipulate the compiler into producing the code that you want.  The point is to provide information to the compiler about details of your application that it cannot figure out by itself, so it can do a better job.

    If you lie to the compiler, it's a user error, whether or not it immediately causes visibly erroneous results.