Long/int max size with -opt-subscript-in-range compiler switch

[dehvidc1]

Using the -guide compiler switch I'm getting a couple of recommendations along these lines:

genomicSelectionBayesA.cpp(1584): remark #30533: (LOOP) Compile with the -opt-subscript-in-range option to vectorize and/or parallelize the loop at line 1584. [VERIFY] Make sure that no loop in the program contains or generates very large integers (typically very large integers >= 2^30).

This message says to use safely the -opt-subscript-in-range compiler switch I need to ensure that I don't have any integers larger than 2**30 in program loops. The Guided Auto Parallelisation message in the compiler documentation says:

[Begin Intel doc text]

GAP Message (Diagnostic ID 30533)

Message

Compile with the %s option to vectorize and/or parallelize the loop at line %d.

Advice

Use option -opt-subscript-in-range (Linux* OS and Mac OS* X) or /Qopt-subscript-in-range (Windows* OS) for the specified file during compilation.

This option helps the compiler vectorize and parallelize the loop at the specified line. You must verify that the loops in the file do not contain very large integers and are not likely to generate very large integers in intermediate computations. A very large integer is loosely defined as follows: On an n-bit machine, a very large integer is typically >= 2^n-2. For example, on a 32-bit machine, a very large integer would be >= 2³⁰.

[End Intel doc text]


So my question is what is the relevant constraint? If I have a 64 bit machine I would have thought that for the compiler to make appropriate vectorisation assumptions in calculations with mixed longs (64 bit) and ints (32 bit) you wouldn't want any of the longs containing integers over 30 bits no matter what the machine's bit size.

Does that sound right?

Thanks

David

[Om_S_Intel]

The compiler is considering anything greater than 2^31 as large integer. It is not considering m/c size. The compiler is considering how many data items it can pack in xmm or ymm registers.

[dehvidc1]

So that would mean the GAP message is incorrect? Saying that the constraint is 2** (n -1) where n is machine bit size.

[Om_S_Intel]

The Intel compiler for Intel 64 considers integer and longsizesas32 bit. The pointer sizeis 64 bit.

The GAP message need to be fixed.

[dehvidc1]

According to this reference:

http://software.intel.com/en-us/articles/size-of-long-integer-type-on-different-architecture-and-os/

this depends on the architecture and OS. This reference states that on Linux IA64 a long is 64 bits. Which is what I would have expected.

Regards

David

[TimP]

long int is 64 bits on Intel64 and IA64 linux, but 32 bits on Windows. All 64-bit OS have native support for 64-bit signed integer single instruction arithmetic, while 32-bit OS require multiple instructions for all 64-bit int arithmetic.

[Om_S_Intel]

Yes, is it different on Windows and linux. You may use the following code to find the size of int, long and pointer.

$ cat hello.cpp

#include

int main()

{

int a = 0;

long b = 0;

int *p;

printf ("size of int = %d\n", sizeof(a));

printf ("size of long = %d\n", sizeof(b));

printf ("size of pointer = %d\n", sizeof(p));

return 0;

}

$ icc hello.cpp

hello.cpp(10): warning #181: argument is incompatible with corresponding format string conversion

printf ("size of int = %d\n", sizeof(a));

^

hello.cpp(11): warning #181: argument is incompatible with corresponding format string conversion

printf ("size of long = %d\n", sizeof(b));

^

hello.cpp(12): warning #181: argument is incompatible with corresponding format string conversion

printf ("size of pointer = %d\n", sizeof(p));

^

$ ./a.out

size of int = 4

size of long = 8

size of pointer = 8

$ uname -a

Linux maya11 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

$ icc -V

Intel C Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.1.107 Build 20101116

Copyright (C) 1985-2010 Intel Corporation. All rights reserved.