IFC code deliberately broken on AMD chips.

mark-mackey · ‎06-25-2004

I've recently upgrade my version of IFC from 7.0.079 to 7.1.040 (version 8.x won't compile my code successfully). As part of this change, code compiled with the -xW flag now crashes on AMD Athlon chips. Looking at the code, it appears that the compiler now deliberately checks whether it's running on an Intel processor and if not disables SSE support, despite the fact that Athlon MP and XP chips do SSE perfectly well.

I had thought that I purchased a compiler from Intel, not a marketing tool. Changing the compiler to deliberately nobble the performance of code when running on a competitor's chip is not IMHO acceptable business practise.

TimP · ‎06-25-2004

The most recent update of 8.0 compilers should have fixed the run-time issue with -xW and -xK on AMD processors. I don't believe the fix has been carried back to 7.1. It's not deliberate, it's an oversight, due to AMD processors not being supportedor tested with those options. Running options which are not supported on your processor is always done at your own risk. If it were deliberate, there would have been an explicit message displayed indicating non-support for your processor, rather than a crash with an unhandled CPUID result.

If you don't file reports on premier.intel.com on your problems with 8.0 compilers, they may not get corrected.

mark-mackey · ‎06-25-2004

No, the problem is deliberate. The older versions of IFC (version 7) produce code that works perfectly well on both Intel and AMD chips. The latest version does not.

What is the difference? The newer version, in the __intel_cpu_init internal function, checks the CPUID for the string "GenuineIntel". If that string is not present, the __intel_cpu_init function sets the CPU capability flags to zero, indicating that the processor doesn't support SSE2 or SSE or MMX or.... Hence if you have compiled code with -xK (which requires SSE support), it will crash on an Athlon XP chip: the code checks whether the CPU supports SSE, incorrectly finds out that it doesn't, and dies.

The code will work fine if compiled with -axK (ie check if SSE is supported, and run generic i386 code if it isn't), but the SSE code will _only_ run on Intel chips and not on any others, even if the other chips are perfectly capable of handling SSE instructions.

This isn't an Intel/AMD compatibility issue. This is a deliberate attempt by the compiler engineers to nobble the performance of IFC-produced code on non-Intel processors.

Steven_L_Intel1 · ‎06-25-2004

I'm a bit confused as to what is going on here.

-xW is supposed to blindly generate code assuming a Pentium 4, without a CPUID check at all. -axW generates two code paths, one that executes on Intel processors only and onethat is a generic code path. It has always worked that way and is documented as such.

If you are seeing a CPUID check with -xW, there's a bug.

Message Edited by sblionel on 06-25-2004 01:43 PM

mark-mackey · ‎06-25-2004

I submitted it as a bug and got a canned answer pointing me to a 4-line 'document' which said 'The Intel compilers are only valid for use on Intel CPUs'.

Steven_L_Intel1 · ‎06-25-2004

I'm a bit confused as to what is going on here.

-xW is supposed to blindly generate code assuming a Pentium 4, without a CPUID check at all. -axW generates two code paths, one that executes on Intel processors only and onethat is a generic code path. It has always worked that way (at least in 7.x) and is documented as such.

If you are seeing a CPUID check with -xW, there's a bug.

Message Edited by sblionel on 06-25-2004 01:50 PM

mark-mackey · ‎06-25-2004

That's true for the code in the main body of the compiled program. However, the ifc compiler links in libimf and libsvml (the Intel optimised maths libraries) automatically. These were obviously compiled with -axW (or designed with equivalent functionality). As a result, any vectorised calls to e.g. exp() get passed through to vmlsExp4:


Dump of assembler code for function vmlsExp4:
0x08103ca0 [vmlsExp4+0]:        testl  $0xffffff00,__intel_cpu_indicator
0x08103caa [vmlsExp4+10]:       jne    0x8103ff0 
0x08103cb0 [vmlsExp4+16]:       testl  $0xffffff80,__intel_cpu_indicator
0x08103cba [vmlsExp4+26]:       jne    0x8103cf0 
0x08103cc0 [vmlsExp4+32]:       testl  $0xffffffff,__intel_cpu_indicator
0x08103cca [vmlsExp4+42]:       jne    0x8169ef8 <__intel_cpu_dispatch_fail>
0x08103cd0 [vmlsExp4+48]:       call   0x8169e04 <__intel_cpu_indicator_init>
0x08103cd5 [vmlsExp4+53]:       jmp    0x8103ca0

In the old __intel_cpu_indicator_init() __intel_cpu_indicator is set to 128 on an Athlon XP (ie SSE available), so vmlsExp4 calls vmlsExp4.H and we're OK. In the new version, __intel_cpu_indicator is set to 1 (this is Not Intel), and we're off to __intel_cpu_dispatch_fail() which signals SEGV.

The fact that the linked-in libraries are all compiled with the -ax flags causes other problems (eg with programs migrating between architectures under openMosix), but that's a completely different whinge.

Anyway, the fact is that even if the -ax flags are not specified the corresponding code is still used, and the 'is this an Intel CPU' check in IFC 7.1.040 breaks programs on AMD processors completely unnecessarily. If I compile with -axK then the program works, but it doesn't use any of the SSE code on Athlons despite the fact that it works perfectly well and is faster.

Intel_C_Intel · ‎06-25-2004

What do you expect? Intel doesn't see compilers to make money, they sell compilers to enable their technology. Price out the difference between Intel and Portland Group and notice how much more the Portland Group is going to cost.

There was a discussion about this on the news groups a few months ago. I think
it was on comp.arch or the beowulf list, but I cannot find it right now.

Craig

mark-mackey · ‎06-25-2004

Microsoft cobbling Windows so that it gave spurious error messages when running on DR-DOS rather than MS-DOS wasn't acceptable, so I don't see why this should be. If Intel was giving ifc away for free as a way of 'enabling their technology', then fine: in that case I'd be quite happy with their checking CPUID and refusing to run at all on AMD. However, if I pay for a compiler, I don't expect it to be deliberately crippled. This holds even more when it _used_ to work fine, and then is broken in an upgrade.

Steven_L_Intel1 · ‎06-25-2004

I am not aware that any deliberate changes were made, nor do I know of any plans to change the way -xW and -axW work. If you have found a problem, please report it with an example to support and we'll be glad to investigate. Mark, I saw you did submit a request, and I'm waiting for clarification on the problem description and an example.

mbkennel · ‎06-25-2004

Intel has no obligation to go out of its way to support peculiar AMD-only features, or adapt to AMD-specific scheduling, but it should NOT be testing whether the CPU is GenuineIntel or whatever it does.

On linux do 'cat /proc/cpuinfo'. On the 'flags' line it is clear that it can discern what specific CPU features are available.

The compiler and its support libraries ought to do the same. If "SSE" is available then use it, not whether it's a "Pentium 7" or any specific model.

In fact /proc/cpuinfo is a perfectly decent way to get at this---as the compiler targets Linux specifically.

Steven_L_Intel1 · ‎06-28-2004

As Tim correctly pointed out,this was a bug introduced into the vector math library. It is fixed in the current 8.0 compilers. There are no plans to fix it for 7.1.

Message Edited by sblionel on 06-28-2004 02:32 PM

mark-mackey · ‎07-07-2004

Given that Intel won't fix this, and given that I'm not keen on migrating to 8.0 just yet, I've created a small utility to patch libirc.a to remove the 'GenuineIntel' check. It's a simple Perl script, it's guaranteed not to break anything :), and it's available at http://www.swallowtail.org/intel_check_patch.txt

This patch removes the 'GenuineIntel' check made by the vectorised math library, so code compiled with -axK or -axW will use SSE/SSE2 code on non-Intel processors that support it.