• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 55 subscribers
  • Views 758 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: PCH: memory usage conflict

Dave Smith62
Intellectual 405 points

Hi,

We are testing with precomipiled header,

We first create a pch

"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/bin/armcl" -mv5e --code_state=32 -me --include_path="C:\ti\ccsv6\tools\compiler\ti-cgt-arm_5.2.5\include" --create_pch=foo.pch --pch_verbose --pch_dir=c:\downloads "foo.cpp"

Then

"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/bin/armcl" -mv5e --code_state=32 -me --include_path="C:\ti\ccsv6\tools\compiler\ti-cgt-arm_5.2.5\include" --use_pch=foo.pch --pch_verbose --pch_dir=c:\downloads "foo.cpp"

The .out was built, but the pch never appeared to have been used, and the compilation time in cases of large inclusion is still slow.

Why and how can we solve this?

 

Dave

  • 0
    TI__Guru**** 232670 points

    I don't know the specifics of what has gone wrong here ...

    Dave Smith62 said:
    Warning: memory usage conflict with precompiled header file "c:\downloads\foo.pch"

    But I do know that, for most users in most cases, PCH just plain doesn't work.  That's why it is not available in recent releases.

    Please stop using PCH.

    Thanks and regards,

    -George

  • 0
    TI__Expert 4930 points
    Precompiled headers appear to be implemented not as serialise/deserialise, but as a raw binary dump of data structures. The warning is because the addresses of allocation during creation do not match the addresses during read-for-use. With the warning, the parser ignores the precompiled headers and compiles normally, thus without any speedup.

    I don't know why there is an address mismatch. I'm poking at it because I'm curious, but since we've already disabled precompiled headers in later releases, there's no priority on it.

    Parsing is not often the dominant phase of compilation for large programs, so there may not be much speedup to be had this way. You'd get more from using the CCS parallel-build option and a multicore host, to compile files in parallel.
  • 0 in reply to pf
    Intellectual 405 points

    A1: We use template code and suspect the time was spent on header.  And all recommendations/technical articles from MS, GCC, etc., suggest PCH is for reducing this time.

    Q1: Can we pre-parse a a file, eliminating unused definitions, and later compile only those used definitions?


    Dave

  • 0 in reply to Dave Smith62
    TI__Guru* 84225 points

    1: I suppose you could, but I'm not convinced it will be worth it. You suggest that the parser is a large part of the compilation time overhead, particularly when compiling highly-templateized C++ files like Boost. That hasn't been our experience. The bulk of the time tends to be spent in either the high-level optimizer (armopt), or the backend code generator (armcg). If you are concerned about compilation time, I would suggest always running with -O2; you could turn off optimization (-Ooff) to eliminate the run-time of armopt, but that tends to leave a lot of dead functions that armcg is forced to deal with.

    Please note that the 5.2.x branch is a pretty old compiler; we are not going to be making any compilation speed changes to old branches. I would strongly recommend you try ARM 18.1.x.LTS to see if it is any faster.

    2: The compiler does use more modern optimizations such as software pipelining (for C6000), not all of which are described in the literature. The list of the user's guide is not exhaustive; we don't bother to update it because the average user isn't familiar with the names of optimization techniques. The list in the user's guide are some of the simpler algorithms that people might have heard of, and it's really just there to indicate that yes, we do optimize your code. I suspect that the optimizations you'd be most interested in are in the high-level language optimizer. It does things like data dependence analysis, unroll-and-jam, loop interchange. I'm not very familiar with the current list, so I'll stop there.