• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 722 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.

Compiler: Challenges with integrating CGT8.3.4

Risto Alasaarela1
Intellectual 450 points


Tool/software: TI C/C++ Compiler

Hello!

During making the changes required when taking GGT 8 in use, I have noticed that fast code size of RTS has increased much. Originally (with CGT 7.3.23) we classified following RTS sections as fast (and linked to L2):

AsdRtsFastCodeConst
{
rts6600_elf.lib<divd.obj>(.text)
rts6600_elf.lib<divu.obj>(.text)
rts6600_elf.lib<divi.obj>(.text)
rts6600_elf.lib<expf.obj>(.text)
rts6600_elf.lib<exp2f.obj>(.text)
rts6600_elf.lib<imath64.obj>(.text)
rts6600_elf.lib<ldexpf.obj>(.text)
rts6600_elf.lib<llshift.obj>(.text)
rts6600_elf.lib<memcpy64.obj>(.text)
rts6600_elf.lib<memset.obj>(.text)
rts6600_elf.lib<modff.obj>(.text)
rts6600_elf.lib<push.obj>(.text)
rts6600_elf.lib<remu.obj>(.text)
}

Linker started to complain about long jumps when using this list, and I ended up to this list without any warnings (with CGT 8.3.4):

AsdRtsFastCodeConst
{
rts6600_elf.lib<divd.c.obj>(.text)
rts6600_elf.lib<divu.asm.obj>(.text)
rts6600_elf.lib<divi.asm.obj>(.text)
rts6600_elf.lib<expf.c.obj>(.text)
rts6600_elf.lib<exp2f.c.obj>(.text)
rts6600_elf.lib<fclose.c.obj>(.text)
rts6600_elf.lib<fputc.c.obj>(.text)
rts6600_elf.lib<fputs.c.obj>(.text)
rts6600_elf.lib<fseek.c.obj>(.text)
rts6600_elf.lib<frexp.c.obj>(.text)
rts6600_elf.lib<imath64.c.obj>(.text)
rts6600_elf.lib<ldexp.c.obj>(.text)
rts6600_elf.lib<ldexpf.c.obj>(.text)
rts6600_elf.lib<llabs.c.obj>(.text)
rts6600_elf.lib<llshift.c.obj>(.text)
rts6600_elf.lib<_ltoa.c.obj>(.text)
rts6600_elf.lib<memcpy64.asm.obj>(.text)
rts6600_elf.lib<memset.c.obj>(.text)
rts6600_elf.lib<modff.c.obj>(.text)
rts6600_elf.lib<push.asm.obj>(.text)
rts6600_elf.lib<_printfi.c.obj>(.text)
rts6600_elf.lib<remu.asm.obj>(.text)
rts6600_elf.lib<_scanfi.c.obj>(.text)
rts6600_elf.lib<setvbuf.c.obj>(.text)
rts6600_elf.lib<signbit.c.obj>(.text)
rts6600_elf.lib<wcslen.c.obj>(.text)
}

This lead to a situation, where L2 memory usage is increased like this:

10822000 10822000 00000f60 00000f60 r-x AsdRtsFastCodeConst

->

108231c0 108231c0 000074a0 000074a0 r-x AsdRtsFastCodeConst

Could you explain what has been done for the mentioned parts of RTS? From my perspective 26k increase of L2 memory usage is not acceptable. Do you have any hints how this could be optimized?

Another problem that have observed a strange problem with CGT 8.3.4 RTS header files. With earlier CGT (7.3.23) the strrchr() function is automatically inlined with the linker, but with never CGT I can see, that linker creates different symbols for all use cases of the mentioned function (in .text section). After adding FUNC_ALWAYS_INLINE pragma definition for the mentioned function, symbols disappeared from the memory map. I have observed similar kind of phenomenon also with some functions that have been defined by Nokia (inlined as expected with CGT7, but pragma required with CGT8).Are you able to explain the behavior?

Please find the changed header as attachment:

string.h

Br,

Risto Alasaarela

  • 0
    TI__Guru**** 251690 points

    Regarding ...

    Risto Alasaarela1 said:
    I have noticed that fast code size of RTS has increased much.

    What is the criteria you use to decide whether an RTS function becomes part of the output section AsdRtsFastCodeConst?  

    Regarding the difference in whether functions get inlined ... Please show all the build options you use when compiling and when linking.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 450 points

    What is the criteria you use to decide whether an RTS function becomes part of the output section AsdRtsFastCodeConst?  

    We have made some profiling, and based on that have selected the object files that will be classified as fast code.

    Please find the compiler and linker options in the attached files.

    Br,

    Risto

    Fullscreen 5736.compiler_flags.txt Download 
    /var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/E_External/TI_deliverables/CGTools/CGT834/bin/cl6x Services/AaFileTransfer/src/SicFtpServer/AaFileSicFtpServer.c  --mem_model:data=far -pdse9 -pdse48 -pdse190 -pdse225 -pdse262 -pdse849 -pdse994 -mi1000 -mv6600 -mo --strip_coff_underscore --disable_push_pop -D__TCC__ -DPLATFORM_DEVICE_KEPLER -DAASYSCOM_USE_INLINE_IMPL -DAACPU_USE_INLINE_IMPL -DAAMEM_USE_INLINE_IMPL -D__CCS_INLINE__=inline -DCCS_NEW_IF_STRUCTURE -DCCS_COMMON_API -DCCS_DSP_API -DCCS_OSECK   -dC66x -DFE_PLATFORM_FSPB -DFE_PLATFORM -DCCS_LITTLE_ENDIAN -DIPDRIVER_STACK -DFE_PLATFORM_ETHERNET_USED -DBMM_PACKAGE -DUSE_BMM_BLOCK_END_MARKS -DBMM_ERROR_CHECKS -DAASYSCOM_DSP -DCCS_OSECK -DCCS_DSP -DAAERROR_DSP -DAAFILE_DSP -DAATRACE_DSP -DAACPU_DSP -DAASTARTUP_DSP -D_TMS320C6X -D__CCS_INLINE__=inline -DAACONFIG_NO_FILESYS -DAACONFIG_UNSAFE_STARTUP -DAATRBL_DSP -DAACONTAINERS_DSP -DAAHELPERS_DSP -DAATBTS_DSP -DAASYSDISPATCHER_DSP -DAARTOSAPI_OSECK_INLINE -DAASYSMB_DSP -DAACONFIG_STATIC_RAD_MASTER -d"C64PLUS_CORE=1" -dxdc_target__littleEndian -dDECODER_DRIVER__DEBUG -DCCS_OSECK -DLITTLE_ENDIAN   -q -pdr -pden -pdse179 -pdse195 -pdse238 -pdse270 -pdse880 --emit_warnings_as_errors -ppa -ppd="Services/obj/KeplerWmp/CGT834/AaFileTransfer/AaFileSicFtpServer.md"  -o3 -ms0 -pds=238   -dC66x -DFE_PLATFORM_FSPB -DFE_PLATFORM -DCCS_LITTLE_ENDIAN -DIPDRIVER_STACK -DFE_PLATFORM_ETHERNET_USED -DBMM_PACKAGE -DUSE_BMM_BLOCK_END_MARKS -DBMM_ERROR_CHECKS -DAASYSCOM_DSP -DCCS_OSECK -DCCS_DSP -DAAERROR_DSP -DAAFILE_DSP -DAATRACE_DSP -DAACPU_DSP -DAASTARTUP_DSP -D_TMS320C6X -D__CCS_INLINE__=inline -DAACONFIG_NO_FILESYS -DAACONFIG_UNSAFE_STARTUP -DAATRBL_DSP -DAACONTAINERS_DSP -DAAHELPERS_DSP -DAATBTS_DSP -DAASYSDISPATCHER_DSP -DAARTOSAPI_OSECK_INLINE -DAASYSMB_DSP -DAACONFIG_STATIC_RAD_MASTER -d"C64PLUS_CORE=1" -dxdc_target__littleEndian -dDECODER_DRIVER__DEBUG -DCCS_OSECK -DLITTLE_ENDIAN    -IServices/AaFileTransfer/src -IServices/AaFileTransfer/src/SicFtpClient -IServices/AaFileTransfer/src/SicFtpServer -I../CCS_DSP/Services/AaSysCom/src -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/CCS_ENV/DSP/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/CCS_ENV/DSP/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/CCS_ENV/DSP/ServiceInterface -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/CCS_ENV/COMMON/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/CCS_ENV/COMMON/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/CCS_ENV/COMMON/ServiceInterface -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Platform_Env/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Global_Env/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/I_Interface/Global_Env/Messages -I/var/fpwork/ralasaar/uphwapi/C_Platform/CCS_COMMON/Services/CcsCommonInternalInterface -I../include -I../DSPHWAPI/Services/include/ -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Global_Env/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Global_Env/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/UPHWAPI_ENV/DSPHWAPI_ENV/KEYSTONE_ENV/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/UPHWAPI_ENV/DSPHWAPI_ENV/KEYSTONE_ENV/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/UPHWAPI_ENV/DSP_AND_RTHWAPI_ENV/KEYSTONE_ENV/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/UPHWAPI_ENV/DSP_AND_RTHWAPI_ENV/KEYSTONE_ENV/Definitions/openem/ti -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/UPHWAPI_ENV/DSP_AND_RTHWAPI_ENV/KEYSTONE_ENV/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/UPHWAPI_ENV/DSP_AND_RTHWAPI_ENV/COMMON_ENV/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/UPHWAPI_ENV/DSP_AND_RTHWAPI_ENV/COMMON_ENV/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/CCS_ENV/DSP/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/CCS_ENV/DSP/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/CCS_ENV/DSP/ServiceInterface -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/CCS_ENV/COMMON/Definitions -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/CCS_ENV/COMMON/Messages -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4//I_Interface/Platform_Env/CCS_ENV/COMMON/ServiceInterface -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/E_External/ose41x_cgt834/320c66x_le/include -I/var/fpwork/ralasaar/uphwapi/SCI_Interface_FSM4/E_External/TI_deliverables/CGTools/CGT834/include -I/C6000/cgtools/include -D__T

    kepler_lte_CPU1.txt

  • 0
    TI__Guru**** 251690 points

    For now, I presume this explanation is correct.  You started adding RTS functions to the output section AsdRtsFastCodeConst because profiling information says these functions need to be in faster memory for you to meet your goals for system performance.  Then you started to see this ...

    Risto Alasaarela1 said:
    Linker started to complain about long jumps when using this list

    To avoid those linker diagnostics, you add more RTS functions to the output section AsdRtsFastCodeConst.  Please show me, by copy-n-paste, the text of one of these linker diagnostics.  There might be other ways to handle it.  Or, it may make sense to ignore them.

    Regarding the problem where strrchr does not inlined ... I can reproduce this behavior.  It appears to be a problem in the compiler.  I filed the entry CODEGEN-6789 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

  • 0 in reply to George Mock
    Intellectual 450 points

    Hello!

    With initial linking group I observe this problem:

    /var/fpwork/ralasaar/workspace/uphwapi/SCI_Interface_FSM3/E_External/TI_deliverables/CGTools/CGT834/bin/cl6x -@/var/fpwork/ralasaar/workspace/uphwapi/C_Platform/DSPHWAPI/TestCodes/lib/Nyquist/CGT834/ALL/nyquist_lte_CPU1.lcf
    <Linking>
    error #10247-D: creating output section ".text" without a SECTIONS
    specification
    error #10370-D: Possible codesize or performance degradation. Section
    ".text:__TI_printfi:rts6600_elf.lib<_printfi.c.obj>" has calls to rts
    routines, but rts is placed out of range from call site at 0x808c68, or in a
    different section. To optimize codesize, either 1) place rts closer to call
    site, or 2) place rts in same section, or 3) compile with
    --disable_push_pop.
    error #10370-D: Possible codesize or performance degradation. Section
    ".text:__TI_printfi:rts6600_elf.lib<_printfi.c.obj>" has calls to rts
    routines, but rts is placed out of range from call site at 0x806ca0, or in a
    different section. To optimize codesize, either 1) place rts closer to call
    site, or 2) place rts in same section, or 3) compile with
    --disable_push_pop.
    error #10010: errors encountered during linking;
    "../Out/Nyquist/Lte/nyquist_CPU1.out" not built


    Are the long jumps observed by the linker in used by the fast path of the RTS functions? How to prevent the compiler linker warning? I cannot compile RTS functions by myself by adding  --disable_push_pop flag. This flag has been added for my own libraries already.

    Br,

    Risto

     

  • 0 in reply to Risto Alasaarela1
    TI__Guru**** 251690 points

    Regarding ...

    Risto Alasaarela1 said:
    error #10247-D: creating output section ".text" without a SECTIONS
    specification

    You have to fix this error.  It says you are creating an output section named .text automatically.  In particular, this .text output section is placed in memory according to the linker default settings, which are almost certain to be wrong for your system.  Change the linker command file to explicitly place .text in an appropriate memory range.

    Regarding ...

    Risto Alasaarela1 said:
    error #10370-D: Possible codesize or performance degradation. Section
    ".text:__TI_printfi:rts6600_elf.lib<_printfi.c.obj>" has calls to rts
    routines, but rts is placed out of range from call site at 0x808c68, or in a
    different section. To optimize codesize, either 1) place rts closer to call
    site, or 2) place rts in same section, or 3) compile with
    --disable_push_pop.

    Please see this forum thread.  Please consider one additional solution not mentioned in that thread: You can disable this diagnostic with the linker option --diag_suppress=10370.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 450 points

    Hello!

    Regarding to .text section; yes I know how to correct it. My concern is that are these pieces of code that appeared when starting to use CGT8 including to the fast path of RTS functions? Is it safe to link them to external memory? My expectation was initially no, and I linked them to L2, leading to increase of 26kB of L2 memory. Please Look at the list of linked object files with CGT7 and CGT8 at The beginning of this chain.

    BR,

    Risto

  • 0 in reply to Risto Alasaarela1
    TI__Guru**** 251690 points

    Risto Alasaarela1 said:
    Is it safe to link them to external memory?

    There are two considerations, and I can only answer one of them.  One: Will execute correctly?  Yes.  Two: Will it run fast enough?  I don't know.  If it is practical, try it both ways and see.

    If you want to get into more detail on the performance aspects of your system, then I recommend you start a new thread in the Processors Forum.  They will want to know exactly which C6000 processor you use.

    Thanks and regards,

    -George