• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 197 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.

ARM-CGT: ARM-CGT v20.2.7 linkage (armcl) is slower than v18

Yohei Y
Prodigy 10 points

Part Number: ARM-CGT

Our project uses CCS/ARM-CGT to develop firmwares for AM335* sitara processors. We recently upgraded the toolchain from v18.12 to v20.2.7 and the initial build time has increased a lot. It's fine to stick with the old toolchain, but I want to know what is happening behind, and if possible use the latest version. 

CCSv9 + CGT v18 = current (~60min)
CCSv9 + CGT v20 = Stucks long during link phase
CCSv12 + CGT v20 = Stucks long during link phase
CCSv12 + CGT v18 = ~60min

From our observations above, I suspect some change happened in v20 link phase. Code optimization are disabled (during development), and project settings are kept same. 

Does anyone have some clues? 

 

  • 0
    TI__Guru**** 253420 points

    I have a question into the compiler development team.  I expect to get back to you tomorrow.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 253420 points

    Between versions 18.12.x.LTS and 20.2.x.LTS, we are aware of no changes that would likely cause the linker to be slower.  So, we need a test case that allows us to investigate.  

    Since your build, even with v18, takes an hour to link, I presume it is a very big build with lots of files and libraries.  I'm looking to see if we already have a test case that uses lots of files.  If that does not work out, we may have to ask for a test case from you.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 10 points

    Hi George

    Thank you for the investigation. 
    Here are some supplementary information that may help.

    Laptop Spec:
    Windows 11 Pro, CPU: core-i7 1370P, RAM: 32GB, SSD: NVME SSD
    Anti-Virus: Enabled

    Program:
    ELF file size (no opt): 168MB
    ELF file size (with opt): 122MB
    Binary file size (no opt): 1.6MB
    Binary file size (with opt): 0.8MB

    1) Our project is unique that we use C++ Math library (Eigen).
    I'm sure this is causing the long compilation and optimization. The CDT build console stalls a while, showing "building file: xxx".
    We use C-macro to generate tons of functions - Not all are used, and those are removed from the firmware by the linker.

    2) The optimization algorithm is options: -O3 --opt-for-speed=5 (Applied only to the math related files)

    3) In the first post I wrote "Stucks long during link phase" -- the measured time turned out to be around 100mins.
        Maybe the time vary due to the machine workload. I haven't tested repeatedly because it takes time.

  • 0 in reply to Yohei Y
    TI__Guru**** 253420 points

    Please see the note near the bottom of the first page of the tiarmclang online manual.  It explains that tiarmclang replaces armcl.  Only bug fixes are applied to armcl.  This case, however, is not a bug.  It is a performance issue.  Even if we found the root cause, it is unlikely to be addressed.    

    All things considered, I don't think it makes sense to continue working through this issue. You are welcome to disagree, and ask me to try anyway.  If so, then I need a test case from you.  Is this something you would consider?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 10 points

    Hi

    OK, I understood the situation. Since we're also not ready to fully work on this issue, and probably won't happen soon; therefore I won't request for further support. 

    I knew tiarmclang is replacing armcl, but Cortex-A is not supported by it. Here I reached for help  because if it can be fixed, we can confidently switch to the maintained toolset, and keep using the industrial GHz processors in our new product. 

    But anyways, Thank you very much for the response.

    Best regards,
    Yohei