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.

Compiler/TMS320F28377S: pragma FUNCTION_OPTIONS not overriding project flags

Part Number: TMS320F28377S

Tool/software: TI C/C++ Compiler

Hi,

I am using compiler TI v15.12.1.LTS for the F28377s, and CCS 7.0.x.  I have a function containing a loop that I have hand optimized with NOPs to execute in exactly 250 clocks.  So I would like to be able to modify the project's compiler optimizations while holding this function with no optimizations so my loop remains constant.  However, whether I set the project to -O0 and the FUNCTION_OPTIONS pragma to

#pragma FUNCTION_OPTIONS (send_led_data, "--opt_level=3")

or vice-versa, it appears that the function send_led_data is still being compiled with the project's -Ox flag and the pragma is ignored.  Perhaps I am missing some other setting to make FUNCTION_OPTIONS work?

Thanks, dave

  • db_woodall said:
    it appears that the function send_led_data is still being compiled with the project's -Ox flag and the pragma is ignored. 

    What do you see that makes you think this is the case?  Exactly how do you see it?

    Please follow the directions in the article How to Submit a Compiler Test Case to send in a test case for the source file which contains the function send_led_data.

    Thanks and regards,

    -George

  • Hi George,

    This program drives a large panel of WS2812 RGB LEDs, so if the bit bang loop isn't right, the LEDs flash randomly.  I can also tell by looking at CpuTimer1Regs.TIM, which is running at the CPU's 200Mhz rate.

    Tests:  Set a breakpoint on the first instruction in the bit bang loop, then hit it a second time and subtract the timer values:

    1. compile with -Ooff for the project and no function pragma, the loop time is 250 clocks (as expected).
    2. compile with -O2 for the project and no function pragma, the loop time is 27 clocks.
    3. compile with -O2 for the project and enable the pragma to "--opt_level=off", I expect the loop time to be 250 clocks, but it is 194.
    4. compile with -Ooff for the project and enable the pragma to "--opt_level=2", the loop time is 246.
    5. compile with -O2 for the project and enable the pragma to "--opt_level=2", the loop time is 27.

    So, it is doing something, but the function pragma does not produce equivalent code to the project properties setting.  If I could count on it to produce the same code with the same function pragma regardless of what the project setting is, I could re-tune the loop for -O2 and leave it.  I will look at the instructions for sending in the code.

    Thanks, dave

  • Attached is the source.  If you set a breakpoint on line 18457, hit it twice and compare the CPU1 timer values, you can easily see the loop time.  This was built with -O2 for the project and also for the function pragma. The compiler tools version is v15.12.1.

    Thanks!  dave

    led_driver.pp.txt

  • Thank you for sending in the test case.  I cannot run the code.  So I don't know that I have reproduced exactly what you describe.  However, I did see the compiler ignore this directive ...

    #pragma FUNCTION_OPTIONS (send_led_data_13, "--opt_level=off")

    That's not good.  So I filed CODEGEN-3614 in the SDOWP system to have this case investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • The FUNCTION_OPTIONS pragma is interpreted by the optimiser. That implies two things: first, you have to have at least -O0 for the pragma to have any effect at all, and second, --opt_level=off within the pragma won't work because you're already within the optimiser and some minimal processing will always happen. In other words, your cases 3 and 4 cannot be made to behave as you expect.

    Why does the pragma work this way? Well, it was developed internally for an unrelated purpose, then turned out to be useful to an internal project, then was a solution to a customer problem, so we made it public. The behavior reflects the implementation, not an intentional design.

    We may enhance the compiler to fix these wrinkles, but it won't be quickly. Your best bets to achieve what you want are (a) to place your carefully-timed function in its own file, and use CCS file-specific options to compile it as you wish while the rest of the project does its own thing, or (b) to write your carefully-timed function in assembly, which will not only give you precise timing but also insulate against any other compiler vagaries.
  • Thanks George and pf,

    I can certainly compile the file with its own optimization settings.  If the pragma isn't updated, it would be good to document the behavior in the compiler user guide.

    Thanks, dave