CPU type detection hiccups

[inducer]

When the configure script uses llc to detect the host CPU type, I've observed two things going wrong:

• On Haswell machines with LLVM 3.6, it will detect core-avx2 as llc_host_cpu, but then it will die trying to compile a kernel with error: <invalid loc>: unknown target CPU 'core-avx2'. Even weirder, if I manually specify LLC_HOST_CPU=x86-64 ./configure ..., it then comes back with unknown target CPU 'x86-64', although that is one of the targets shown as available in the output of llc --version.
• On Broadwell machines also with LLVM 3.6, it will detect x86-64, which I suppose is slightly different than what it expects in configure.ac here: https://github.com/pocl/pocl/blob/master/configure.ac#L985.

@sj90101

[pjaaskel]

Could someone with the said machine at hands debug this? LLVM 3.7 should be tried too.

[Oblomov]

For what it's worth, I've seen similar issues on systems with mixed LLVM situations; typically, when having both Clover from Mesa (built with LLVM 3.5 on Debian unstable) and pocl (self-compiled on LLVM 3.6); in such cases, things seemed to work correctly when disabling clover completely (i.e. removing its .icd file from /etc/OpenCL/vendors) but would fail at normal runtime. Building pocl with the same LLVM as Clover fixed the issue for me. (IOW, this might not be an issue specific to LLVM 3.6, but rather to having multiple OpenCL platforms built with different LLVM versions on the same system.)

[pjaaskel]

Yes, this has caused problems before. Especially as the tendency with LLVM using projects is to use static linkage for some reason, it has caused problems with symbol clashes.

[pjaaskel]

I understood from #231 that with LLVM 3.7 the detection issue doesn't appear. Thus, closing this now (latest LLVM is the priority). Reopen if I'm wrong.

[inducer]

For what it's worth, @Oblomov was spot on. This issue was actually caused by clover being installed on the machine. Sorry that I forgot to close this issue, and thanks for the hint.