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.

C2000 function symbol aliasing not performed

Hello,

The document SPRU514E states in section 3.11.7 that 

The compiler recognizes a function whose definition contains only a call to another function. If the two
functions have the same signature (same return value and same number of parameters with the same
type, in the same order), then the compiler can make the calling function an alias of the called function.

I'm trying to observe this optimization with my code but it seems I can't get it to work.

I'm trying to alias the SFO function. Its signature is int SFO(void); so I created a function called PWM_calibrateMep like so:

extern int PWM_calibrateMep(void); // declaration in pwm.h

int PWM_calibrateMep(void) { // definition in pwm.c
    return SFO();
}

However, the asm file generated with --optimizer_interlist looks like this:

.sect ".text"

.global _PWM_calibrateMep

;***************************************************************
;* FNAME: _PWM_calibrateMep FR SIZE: 0 *
;* *
;* FUNCTION ENVIRONMENT *
;* *
;* FUNCTION PROPERTIES *
;* 0 Parameter, 0 Auto, 0 SOE *
;***************************************************************

_PWM_calibrateMep:
;*** 57 ----------------------- return SFO();
LCR #_SFO ; [CPU_] |57| 
; call occurs [#_SFO] ; [] |57| 
LRETR ; [CPU_] 
; return occurs ; []

It seems as though the call still occurs within the function. The asm file where PWM_calibrateMep is called also looks like this:

LCR #_PWM_calibrateMep ; [CPU_] |31| 
; call occurs [#_PWM_calibrateMep] ; [] |31|

So it appears function symbol aliasing is not performed after all. How do I get it to work?

Regards,

Pierre

P.S: below is the command line used to compile my source code


"C:/Program Files (x86)/Texas Instruments/C2000 Code Generation Tools 6.0.2/bin/cl2000"
-v28
-ml
-mt
--cla_support=cla0
-O3
--symdebug:none 
--include_path="C:/Program Files (x86)/Texas Instruments/C2000 Code Generation Tools 6.0.2/include" 
--strict_ansi
--super_quiet 
--verbose_diagnostics
--display_error_number 
--emit_warnings_as_errors
--issue_remarks 
--optimizer_interlist 
--printf_support=full 
--asm_listing 
--output_all_syms
--preproc_with_compile
--preproc_dependency="Sources/pwm.pp" 
--obj_directory="Sources" "../Sources/pwm.c"

  • You are looking at the compiler generated assembly.  That's too early to judge whether this particular optimization has occurred.  The linker redirects all calls to PWM_calibrateMep to SFO instead.  If it is successful, then the body of PWM_calibrateMep is removed.  

    Instead, check to see whether the symbol for PWM_calibrateMep is present in your final.out file.  Use the name utility nm2000.  Something like this:

    C:\Your Windows PC>nm2000 final.out | find "PWM_calibrateMep"

    If that symbol is present, then the optimization failed.  The name utility is documented in the C2000 assembly tools manual.

    Thanks and regards,

    -George

  • George,

    I ran the command and the name utility found the symbol.

    I also used the -m option of the linker to obtain a map file with the addresses of all symbols and the result was the same.

    If this means the optimization failed, is there a way to make sure it is performed?

    Regards,

    Pierre

  • I apologize.  I gave you incorrect information.  The linker does not remove PWM_calibrateMep.  Rather, it assigns it the same address as SFO.  Thus, you should check on whether those two symbols have the same address.  Here is one way to do that ...

    C:\Your Windows PC>nm2000 final.out | findstr "PWM_calibrateMep SFO"

    Thanks and regards,

    -George

  • The name utility returns this:

    003e8fe5 T _PWM_calibrateMep
    003e9606 T _SFO 

    The map file contains  this aswell:

    GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name
    address name
    -------- ----
    ...
    003e8fe5   _PWM_calibrateMep
    003e9606   _SFO
    ... 


    Regards,

    Pierre

  • Looking at the implementation, it appears that only EABI can handle cases in which the two functions are in different compilation units, and C28x does not do EABI, only COFF.

    (If C28x does do EABI, then you've turned up a compiler bug.  If not, it's a documentation bug that it doesn't emphasise the need for a single compilation unit.)

  • I can confirm that EABI is not supported for C28x.  -George

  • Hi George,

    Thanks for the answer.

    I've made a few tests and it appears that if the --program_level_compile option is enabled, then function aliasing works; I guess the whole program is considered a single translation unit in this case :)

    Therefore the only cases which won't work are when the aliased function comes from linked object code, such as the SFO lib. Never mind!

    Regards,

    Pierre