-falign-functions=(2|16) - Am I reading this correctly?

[Mark_D_9]

Ingo Molnar recently discovered the performance and effective i-cache effectiveness improvement in Linux kernel functions when they are compiled with -falign-functions=64 with gcc on newer Intel CPUs.  I would like to test this out with the Intel compiler, which we use exclusively for our production code, to see if we notice similar benefits.

However, upon reading the documentation for the Intel C++ compiler options, the -falign-functions= parameter only accepts either 2 or 16.  Am I reading that correctly?

[Melanie_B_Intel]

 align the start of functions on a 2 (DEFAULT) or <n> byte boundary
          where <n> is a power of 2

If n is not a power of 2, we round up

I opened an internal defect report to follow up on this problem.  Thanks for the report.

[jimdempseyatthecove]

Melanie,

Are there any issues (conflicts) when using  -falign-functions=64 together with -fpic? (for the Mac/OSX group).

IOW this would seem to be a contradiction of terms.

Please comment.

Jim Dempsey

[Mark_D_9]

Is there a certain version of the compiler where this is true?  Because on v15.0.3 I receive the following error when attempting to use '=64' as an argument:

icc: command line warning #10159: invalid argument for option '-falign-functions'

However, if I change it to use '=16' then it works fine.

[Melanie_B_Intel]

jimdempseyatthecove wrote:

Melanie,

Are there any issues (conflicts) when using  -falign-functions=64 together with -fpic? (for the Mac/OSX group).

IOW this would seem to be a contradiction of terms.

Please comment.

Jim Dempsey

I asked an engineer on the MacOS team, he replied " I don’t think there are any issues with using these 2 options at the same time.

I guess the user wondered if ASLR (which is default on MacOS and requires pic) could lead to the start of __TEXT,__text to be not aligned at 64 bytes. But, I believe ASLR always has to align it at least by the virtual memory page boundary, so this should never be the case."

[Melanie_B_Intel]

Mark D. wrote:

Is there a certain version of the compiler where this is true?  Because on v15.0.3 I receive the following error when attempting to use '=64' as an argument:

icc: command line warning #10159: invalid argument for option '-falign-functions'

However, if I change it to use '=16' then it works fine.

Yes, it appears that 2 and 16 are the only allowable values in our 15.0 compiler, but that has changed in our 16.0 compiler.  Thanks for pointing this out. --Melanie

[SergeyKostrov]

>>Is there a certain version of the compiler where this is true? Because on v15.0.3 I receive the following >>error when attempting to use '=64' as an argument: >> >>icc: command line warning #10159: invalid argument for option '-falign-functions' >> >>However, if I change it to use '=16' then it works fine. It is possible to workaround the problem with inline assembler directive. In case of a Microsoft / Intel compatible inline assembler it looks very simple: ... void TestFunction( void ) { _asm ALIGN 64 ... } ... So, you need to translate it to a Linux compatible inline assembler.

[jimdempseyatthecove]

void f(void) __attribute(aligned(64)); // prototype
void f(void)
{
...code...
}

You should be able to combine the attribute with the function (instead of prototype), the spec is not clear as to if the attribute is to appear before the { or after the }. You could try each to see which errors out.

Windows uses __declspec(..., preceding the function.

Jim Dempsey

[Mark_D_9]

Melanie,

After finally taking care of licensing issues and then upgrading the compiler on my lab box, I *still* get the following error when attempting to rebuild using '-falign-functions=64':

icpc: command line warning #10159: invalid argument for option '-falign-functions'

mdawson@CHISRVDEV091 $ icpc -v
icpc version 16.0.2 (gcc version 4.8.3 compatibility)

[Judith_W_Intel]

This was fixed on March 14th which means you need 16.0 update 3 (16.0.3) to see the fix.

It looks like you using 16.0.2.

Sorry for the inconveniences

Judy

[Mark_D_9]

Judith,

Upgrading to 16.0.3 resolved the issue.  Thanks for the prompt reply!