Possible optimizer problem?

Marshall Schiring

Other Parts Discussed in Thread: OMAPL138

I'm using CCS version 6.1.1.00022 with compiler v7.4.17 on an OMAP L138.

I have the optimizer turned on for my whole project on level 3. For the advanced optimizer options for speed at '4'. I've noticed that one particular loop in one file causes a failure with the optimizer on (A portion of the array written is zeroed). If I turn off the optimizer for this file, the loop functions as expected. I've attached the loop I've found below:

uint8_T rtb_HexbitstoInteger[12];
uint8_T rtb_RSEncoder241213[24];

typedef struct {
  int32_T B[12];                       
} DW_long_terminator_f_T;
DW_long_terminator_f_T *localDW;

for (i = 0; i < 12; i++) {
  rtb_RSEncoder241213[i] = rtb_HexbitstoInteger[i];
  rtb_RSEncoder241213[i + 12] = (uint8_T)localDW->B[i];
}
Log_print3(Diags_USER1, "after: %d %d %d", rtb_RSEncoder241213[12+0], rtb_RSEncoder241213[12+6], rtb_RSEncoder241213[12+11]);

I suspect that the context in the file is important, so I've attached the file in question. This loop starts on line 164. With the optimizer turned ON, my log print shows all zeros. With the optimizer turned OFF the log print will show valid values. If I insert a Log_print statement between the two lines in the loop, the loop functions as expected and the output array has valid values.

I guess I have a workaround for now (unoptimizing this file), but I'm curious if there's any more testing I can do or if this is a known problem?

7065.long_terminator.txt

over 8 years ago

0 George Mock over 8 years ago

TI__Guru**** 232920 points

I'd like to take a closer look at this problem. Please attach a preprocessed form of that source file. Also show all the build options exactly as the compiler sees them when the problem occurs.

Thanks and regards,

-George

0 Marshall Schiring over 8 years ago in reply to George Mock

Intellectual 745 points

long_terminator.txt

Build options when problem occurs (Project -> Properties -> CCS Build -> C6000 Compiler):

-mv6740 --abi=coffabi -O3 --symdebug:skeletal --include_path="C:/ti_ccs6_1/ccsv6/tools/compiler/c6000_7.4.17/include" --define=omapl138 --diag_wrap=off --diag_warning=225 --display_error_number --diag_suppress=370 --opt_for_speed=4

I've attached long_terminator.txt. Looks like the problem loop has moved to line #20341

0 Marshall Schiring over 8 years ago in reply to Marshall Schiring

Intellectual 745 points

Is there anything else I can do to help provide information to figure this out? I'm currently using the workaround by unoptimizing this one file in my project.

0 Archaeologist over 8 years ago in reply to Marshall Schiring

TI__Guru* 84225 points

It would help to get a main() function that calls the problem function with data and checks the value.

For example, I appended the following to your preprocessed source file, but execution never reached the point in the code where you indicated you had placed LOG_print3.

const int32_T rtCP_pooled_gXBV7U4ddwZW[63] = { 0 };
const int32_T rtCP_pooled_OV8OCbi2ELk7[63] = { 0 };
const int32_T rtCP_pooled_fzdmPBnNM9EB[12] = { 0 };

int main()
{
    const uint8_T rtu_LC[9] = { 0 };
    const boolean_T rtu_Enable;
    boolean_T rty_LongTerminator[288];
    DW_long_terminator_f_T localDW;
    
    long_terminator(rtu_LC, &rtu_Enable, rty_LongTerminator, &localDW);
}

0 Marshall Schiring over 7 years ago in reply to Archaeologist

Intellectual 745 points

Sorry for the delay in my response. I've created an example that looks like it will fail. My log statements show data going into the loop in question and the data is zero coming out. You can add a log during the loop execution and the problem goes away (just like in my original problem description).

I've attached a new prepossessed file with a main appended with relevant data. Hopefully this will get you the information you need!

29026257243,C674X_0,before: 46 8 45,printf,Main Logger,,
29026257686,C674X_0,after: 0 0 0,printf,Main Logger,,

8371.long_terminator.c

0 Archaeologist over 7 years ago in reply to Marshall Schiring

TI__Guru* 84225 points

Okay, I can reproduce a problem with "-mu -mv6740 -O2"; I'll look into this a bit more

0 Archaeologist over 7 years ago in reply to Archaeologist

TI__Guru* 84225 points

I still don't know what the bug is, but you can work around it by adding #pragma UNROLL(1) just before the offending loop.

0 Archaeologist over 7 years ago in reply to Archaeologist

TI__Guru* 84225 points

I've submitted this as SDSCM00052887 for further analysis.

0 Marshall Schiring over 7 years ago in reply to Archaeologist

Intellectual 745 points

Thank you for your prompt analysis, suggested workaround, and communication regarding this problem. I look forward to seeing this fixed in a future release!

0 pf over 7 years ago in reply to Marshall Schiring

TI__Expert 4930 points

Probably the next one. There was a glitch in the vectorisation of the int-to-unsigned-char cast. The process is inhibited by the UNROLL(1) pragma, working around the problem at a slight cost in speed.

Code Composer Studio™︎

Code Composer Studio forum

Possible optimizer problem?