Out-of-memory error when compiling a huge project for 32-bit Windows target for profile guided opts

[meldaproduction]

I have a huge project, that needs lots of optimizations, so I use profile guided stuff, which doesn't really improve performance, but smallers the executables quite a bit (from 50MB to 35MB or so). First it takes a hell of a lot of time to build the executables for generting the profile guided database (or how is it called), but my main problem is that 64-bit version works fine, but 32-bit version evetually (after hours of processing...) ends with out-of-memory error (I have enough memory). So I assume the compiler for 32-bit target is also 32-bit (how else could 64-bit compiler succeed).

Is there a way to use the 64-bit compiler to produce 32-bit binaries? Like some parameter or something? I generally don't understand why selecting a different architecture is done by selecting a different compiler.

[Judith_W_Intel]

Try -m32.

      -m32
      -m64
           Generate code for a 32-bit or 64-bit environment.  The 32-bit
           environment sets int, long and pointer to 32 bits and generates
           code that runs on any i386 system.  The 64-bit environment sets int
           to 32 bits and long and pointer to 64 bits and generates code for
           AMDâs x86-64 architecture. For darwin only the -m64 option turns
           off the -fno-pic and -mdynamic-no-pic options.
 

[meldaproduction]

Thanks for the info, but I need it for Windows, not OSX / Linux.

[Judith_W_Intel]

Sorry, try:

/Qm32     generate code for IA-32 architecture

/Qm64     generate code for Intel(R) 64 architecture

[meldaproduction]

Thank you. Tried and despite the switches are probably working, the 64-bit version compiling 32-bit executables ended with out-of-memory message as well...

[jimdempseyatthecove]

I haven't experimented with POGO ...

You should try to see if it is possible to use the database from the 64-bit POGO to build your 32-bit application. IOW perform POGO on 64-bit then copy the .dyn files to the relevant place for the 32-bit .dyn files then perform the Phase 3 portion of the compile of the 32-bit application.

I do not know the appropriate option to inform the compiler to use the already existing .dyn files for final build. The option Qcov-file alone may work but there may be an additional option required as well.

Can someone here provide the additional information.

Jim Dempsey

[meldaproduction]

Thanks Jim, but sadly that doesn't work. ICC froze just a few seconds after tryng that, I let it frozen for like an hour, but nothing...

[Kittur_G_Intel]

@meldaproduction:   Hi, with what I gather reading the thread it appears the compiler is running out of memory when you build using the 64 bit compiler for 32 bit target while 64-to-64 worked fine. Can you provide more details:

1)  Does the error occur during prof gen  or prof-use phase?
2)  Are you using -ipo switch? 
3) What is the system (OS, GCC version etc) you're using?
4) ICC version you're using (%icc -V) should output the values.

_Thx,
Kittur
 

[meldaproduction]

Well, I already stated most of it... anyway

1) prof-gen

2) -ip

3) Windows, command line

4) 15.0.4.221

[Kittur_G_Intel]

Hi,
Thanks for the info. Is it possible for you to compile individual file at a time so you can isolate the particular problematic file? Once you do, you can then use /P option to generate the preprocessed file that we can use as a reproducer for investigation.  My guess is that it could be a bug or it could be that you may be stressing the system with a lot of parallel builds. You can try to reduce the number of maximum number of builds and see if it helps as well.   If you can attach the preprocessed file for that culprit file that would be ideal, thanks

_Kittur

[meldaproduction]

Hi Kittur,

I'm afraid I cannot do that. I'm compiling just 3 source codes and these are huge, I basically include the CPPs together, it has proven to be faster and generate better code. It's all full of templates anyway. But I guess that could be the problem. I'm also not doing any parallel compiling, and the system has plenty of memory.

[Kittur_G_Intel]

Understood, thanks for the info.  Well, the only other thing to try out then is to not use -ip  and/or use –Ob0 on the –prof-gen step and see if it helps.

_Kittur

[meldaproduction]

Thanks for the info, will try!

[Kittur_G_Intel]

Thanks, let me know if it resolves the issue - appreciate much.

_Kittur

[meldaproduction]

Very well, without -ip it works! Now a different problem - on OSX I'm using ICC only for 64-bit, and then I can compile the 64-bit -prof-gen, but then the -prof-use freezes. I'll check again though.

[Kittur_G_Intel]

Great to know, thanks. On the freezing issue, it's the same scenario as before in that it's hard to investigate without the preprocessed file at least :-( Yes, please check again and let us know - appreciate much.

_Kittur

[meldaproduction]

Ok, so on OSX it doesn't work at all! Here's the result:

dyld: Library not loaded: @loader_path/libcilkrts.5.dylib
  Referenced from: /opt/intel/composer_xe_2015.3.187/bin/intel64/profmerge
  Reason: image not found
icpc: error #10106: Fatal error in /opt/intel/composer_xe_2015.3.187/bin/intel64/profmerge, terminated by trace trap

I tried reinstalling the whole thing, no luck...

[meldaproduction]

I fixed that by placing all the libs to /usr/local/lib, interestingly adding that path to PATH didn't help... Anyway then it after some time failed again with this:

": internal error: ** The compiler has encountered an unexpected problem.

** Segmentation violation signal raised. **

Access violation or stack overflow. Please contact Intel Support for assistance.

I'll try without -ip.

[Kittur_G_Intel]

Hi, I don't have the exact system info you're running on but wanted to point out that there was an issue with DYLD_LIBRARY_PATH setting and don't know if it could be a result of that as well. Can you please refer to the article at: https://software.intel.com/articles/os-x-1011-support-in-intel-parallel-studio-xe-2016 and the section under "Dynamic Library Dependencies" and use the workaround indicated there and see if the issue of finding/loading the dynamic lib is taken care of. Also, you'll need to ensure you're using the latest 16.0 Update 1 release as well.  Let me know what you find. Again, appreciate your patience and your feedback through this.

_Kittur

[meldaproduction]

Copying it to the /usr/local/lib did the trick, but with -ip it failed with the message above. I tried without -ip and it worked, but then it didn't bring any performance nor size improvement, so I'll just stick with -ip. It's a shame, because on Windows it works and helps quite a bit (more like for size, but slightly for performance as well).

[Kittur_G_Intel]

Hi, I understand the concern. Since you say it did work without -ip then it could be a bug in the compiler. Unfortunately it's hard for me to file an issue with our developers without a reproducer as you can imagine. I'll bring this to their attention as well and will keep you updated, thx.

_Kittur