This is an archive of the discontinued LLVM Phabricator instance.

Fix llvm + clang build with Intel compiler
Needs ReviewPublic

Authored by yvvan on Mar 13 2018, 7:07 AM.

Details

Summary

I've tested it on Windows with 64-bit icl

These are mostly workarounds for https://software.intel.com/en-us/comment/1919743 , https://software.intel.com/en-us/forums/intel-c-compiler/topic/749369 and few more enum-related issues

Diff Detail

Event Timeline

yvvan created this revision.Mar 13 2018, 7:07 AM

I don't think we should add workarounds for broken compilers.

I don't think we should add workarounds for broken compilers.

I don't follow. What should we do then? If LLVM doesn't compile on a compiler which we claim is supported, then how should we proceed?

Is that compiler really supported? Look at this:

void operator delete(void *) = delete;

It's been there in the code since early 2015. The bitwise OR on ELF::xxx has been there even longer.

Are you telling me that we officially support a compiler, but nobody has actually used it for more than 3 years? What's going on here?

yvvan added a comment.EditedMar 19 2018, 5:43 AM

@nhaehnle And that's the problem. There's no build machine for intel compiler and nobody cares.
And if somebody like me want to build it - there's no solution rather than searching for workarounds yourself.
This patch is not that complex in the end as you see so it should be possible to support one more compiler with not too many headache.

That's why I suggest this patch to at least make people know that it's possible to build. Or probably to grab someone's interest to the problem and set up builds.

erichkeane added a subscriber: erichkeane.

Adding @mibintc to take a look, as she's a good representative of the ICC dev team.

I added some inline comments. You are using the Intel 18.0 compiler on Windows - what version of Visual Studio is in the environment?

include/llvm-c/Target.h
25

I really think all the Intel-compiler bug workarounds should be version specific. For example, in the boost.org customizations we have checks like this:
#if defined(INTEL_COMPILER) && (INTEL_COMPILER >= 1500)

I believe you are using the most recent Intel compiler, 18.0, which has version 1800. Let's assume the bug will either be fixed in our 18.0 compiler or in our next compiler which would be numbered 1900, so the check could be like this:
#if defined(INTEL_COMPILER) && (INTEL_COMPILER < 1900) // employ the workaround for the Intel 18.0 compiler and older

This way the workaround will "disappear" when the bug gets fixed.

For that matter I wonder if it's still necessary to use the workaround for the Microsoft compiler?

Thanks for reporting the bug into the Intel forum. If we put a bug workaround into LLVM it would be very nice to have the bug reported to the offending compiler.

include/llvm/ADT/BitmaskEnum.h
73

what problem is being worked around here? I checked your post into the Intel compiler forum "enum members are not visible to template specialization" and I can observe the bug on our Windows compiler but not our Linux compiler.

include/llvm/Analysis/AliasAnalysis.h
254

is this a necessary workaround for the Intel compiler? It's not pretty. Suggest we add the #if around it? Long term i hope this would not be necessary.

lib/Target/AMDGPU/SIISelLowering.cpp
6131

this assesrts with Intel compiler? Or the expression needs to be rewritten with static_cast as above?

yvvan added a comment.Mar 21 2018, 1:36 AM

I added some inline comments. You are using the Intel 18.0 compiler on Windows - what version of Visual Studio is in the environment?

Yes, I'm using 18.0

include/llvm-c/Target.h
25

This one will probably not be fixed because I was answered that it's the predicted behavior and that I need not to "#define inline __inline" if I use intel compiler
I agree though about versions which need to be taken into account

include/llvm/ADT/BitmaskEnum.h
73

it was recently accepted. the issues is that E::LLVM_BITMASK_LARGEST_ENUMERATOR from line 80 here is always invalid with intel compiler and the whole set of operator overloads is ignored
at least on Windows :)

include/llvm/Analysis/AliasAnalysis.h
254

i'm not sure that adding #if around makes it easier to understand :)
of course I can add it everywhere I append enums with static_cast<int>

lib/Target/AMDGPU/SIISelLowering.cpp
6131

"needs to be rewritten with static_cast" - correct. it can be done but I was a bit lazy and statioc_assert does not affect the outcome of build :)

mibintc added inline comments.Mar 21 2018, 8:37 AM
include/llvm-c/Target.h
25

thanks

include/llvm/ADT/BitmaskEnum.h
73

Thanks. I found the bug report for this one in the icc bug tracking database. It's CMPLRS-47898. With luck it will be fixed in the next update (ballpark based on previous release cadence, 3 months)

include/llvm/Analysis/AliasAnalysis.h
254

The modification for the Intel compiler is so ugly that I'd rather it get wrapped with the #if, and eventually the workaround could get discarded. Imagine yourself 20 years from now staring at that code and wondering why it is written that way. The #if makes it stand out, and easier to find later, and easier to restore to pristine state, when you want to clean it up.

I tried a small test case with the Intel compiler but i couldn't see the problem, must be too simple-minded.
typedef enum { a,b,c,d,e } letters;
char conv( letters l) {

switch(l) {
case a: return 'a';
case a | b : return 'b';
default : return 'z';
}

}

lib/Target/AMDGPU/SIISelLowering.cpp
6131

ok, it's got the if intel so: lgtm