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: C2000 Compilers 6.2.0 / 17.3.0.STS Code Size Issue

Other Parts Discussed in Thread: TMS320F2812

Tool/software: TI C/C++ Compiler

Hello everyone

TL:DR: new compiler with highest optimizations generates much larger asm-code than the old one.

My question is related to the size of code, that is produced by two different compilers. We have a really large project for TMS320F2812 MCU. This project is being developed for some years by this moment, growing larger and larger, it was migrated from CCS3.3 to CCSv5 and so on. This project utilizes about 95% of available memory of the MCU. 

The problem is, that this project is built with C/C++ Compiler v6.2.0. I've discovered on this forum, that it's strongly recommended not to use that, so I decided to build it with v17.3.0 STS. But the build failed due to increased code size. I've tried to change Optimization levels, and set maximum optimization with the highest priority for code size - it doesn't help. Unfortunately, I'm not familiar with the assembler language, so I cannot perform a good analysis of the generated code.

I've compared .map-files and chose an .obj-file which had difference in code size. I've compiled it with different optimization levels. But it seems that non-optimized code of 6.2.0 is still smaller than the high-optimized code of 17.3.0. 

Here are some line of the source code, and generated ASM-files. Could someone please check these files? Maybe i should turn some additional options on? I am also providing compiler call for this files.

Source code for the screenshot function:

void dlog_background_analizer(TDataLog *p) {
	p->trig_shift_int = (p->trig_shift&0xFFFFFF)>>16;
	if (p->trig_shift_int > 255)	
		p->trig_shift_int = 255;

	TCo_OdVars *pco_vars = &co1_vars; 
	unsigned char mode;

	if (!(p->control & 0x3F))
		return;

	p->mode_reset = 0;
	p->valid_points_num = 0;	

	if (p->control & 1)
		if (!(p->dlog_iptr1 = (type_data*) co_getAddr(pco_vars, p->ind_subind1))) 
			p->dlog_iptr1 = (type_data*) &p->ind_subind1; 
	if (p->control & 2)
		if (!(p->dlog_iptr2 = (type_data*) co_getAddr(pco_vars, p->ind_subind2)))
			p->dlog_iptr2 = (type_data*) &p->ind_subind2;
	if (p->control & 4)
		if (!(p->dlog_iptr3 = (type_data*) co_getAddr(pco_vars, p->ind_subind3)))
			p->dlog_iptr3 = (type_data*) &p->ind_subind3;
	if (p->control & 8)
		if (!(p->dlog_iptr4 = (type_data*) co_getAddr(pco_vars, p->ind_subind4)))
			p->dlog_iptr4 = (type_data*) &p->ind_subind4;
	p->WriteDelimiter = (p->control >> 16) & 0xFF; 
	mode = (p->control >> 4) & 3;
	p->control = 0; 
	dlog_set_mode(mode, p); 
}

v6.2.0.asmv17.3.0.asm

  • The only way to understand what is going on is to reproduce these results ourselves.  For that, we need a test case.

    Disona said:
    I've compared .map-files and chose an .obj-file which had difference in code size.

    Good.  Regarding that source file, please follow the directions in the article How To Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • Hello, George

    Sorry for this late answer. The preprocess file is in pastebin: https://pastebin.com/m6twVGvs

    Compiler options for 6.2.0: 

    "C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_6.2.0/bin/cl2000" -v28 -ml -mt -O2 --include_path="C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_6.2.0/include" --include_path="../include" --include_path="../Vinclude" -g --relaxed_ansi --cpp_default --preproc_with_compile --preproc_with_comment --define=_DEBUG --define=LARGE_MODEL --display_error_number --diag_wrap=off -k --obj_directory="Vsrc"  "../Vsrc/V_data_log.c"

    Compiler options for 17.3.0:

    "C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_17.3.0.STS/bin/cl2000" -v28 -ml -mt -Ooff --opt_for_speed=0 --include_path="C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_17.3.0.STS/include" --include_path="../include" --include_path="../Vinclude" --advice:performance=all --define=_DEBUG --define=LARGE_MODEL -g --relaxed_ansi --cpp_default --preproc_with_comment --preproc_with_compile --diag_wrap=off --display_error_number -k --flash_prefetch_warn --obj_directory="Vsrc"  "../Vsrc/V_data_log.c"

  • Unfortunately, I am unable to access pastebin.com.  Please attach the file to your next post, as described in the sub-section titled Attach Preprocessed File to a Forum Post of the article How to Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • Ok, George, the file is attached.

    V_data_log.pp.txt

  • Thank you for letting us know about the issue, and submitting a test case.  I can reproduce the code size increase.  I filed CODEGEN-3673 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

  • Please try with C2000 CGT v17.9.0.STS and see if the problem has been resolved. 

    Thanks,

    Anna

  • Thank you for the update notification.

    I've tried 17.9.0 - it's much better, I should say. The project can be compiled, when "size/speed" tradeoff is set to 1 or 2, so the code fits into available memory. But still, 6.2.0 shows better performance results - comparison was performed by measuring ISRs duration in two projects build with different compilers.

    Could you provide some details on problems, that were fixed? I couldn't find codegen-3673 problem closed in the compiler description, but the most similar closed defect was codegen-2343.

  • Yes, I believe the relevant fix was Codegen-2343.  This first appeared in v16.9.5.LTS and v17.9.0.STS.

    Please provide more detailed performance degradation information.  Which settings are you comparing, which functions are showing the degradations, percentage degradation, etc.  If you use size-speed tradeoff of 3, does the code no longer fit in available memory?  The default setting is 2.

    According to our tests 17.9.0.STS actually slightly improved code size over 6.2.0-- were you seeing this as well?  These are the code size numbers our engineer got on the example test case:

    "data_log_update",0x0000001f,0x00000126,263
    "dlog_background_analizer",0x00000000,0x00000085,133
    "dlog_set_mode",,0x00000000,0x0000001f,31 

    I'm going to close the code size issue but we can open a new issue for performance if there is a significant gap.  Some minor fluctuations between releases are unavoidable.

    Thanks,

    Anna

  • Yes, you can close that issue. When i have possibility to compare new compiler with different settings with the old one, i'll do it and provide information for you. Thank you.