Produce Linux object files under Windows

[Steve Hill]

(This is a follow on from the thread in the user's group but I thought that this is now better in the developer's group. The original thread is https://groups.google.com/forum/#!topic/ispc-users/aNrcsFZIVMo)

I have now managed to build the host version of ISPC from source. However, I did encounter a couple of issues about which I would be grateful for some advice:

1. I have downloaded and built LLVM 5.0.2. It is not clear to me which patches from ispc/llvm_patches I should apply. I've applied 5_0_r317463_better_permute.patch but I'm unsure whether to apply the LLVM 3.x patches too?
2. I am using MSVS 2017 and LLVM built successfully but I got some warnings:

llvmutil.obj : error LNK2019: unresolved external symbol "public: void __thiscall llvm::Value::dump(void)const " (?dump@Value@llvm@@QBEXXZ) referenced in function "void __cdecl lDumpValue(class llvm::Value *,class std::set<class llvm::Value *,struct std::less<class llvm::Value *>,class std::allocator<class llvm::Value *> > &)" (?lDumpValue@@YAXPAVValue@llvm@@AAV?$set@PAVValue@llvm@@U?$less@PAVValue@llvm@@@std@@V?$allocator@PAVValue@llvm@@@4@@std@@@Z)

plus similar warnings in opt.cpp. I commented out the calls to dump() in these two files (assuming that they are mainly for debugging) and ISPC then compiles and can successfully generate host object files.

Any advice on the issues?

Cheers,

S.

[Steve Hill]

OK, I've dug further on the unresolved symbols and it appears that the dump() methods have been removed from the release build of LLVM in v5.0. From this LLVM dev group post:

dump() is meant as a helper for people using a debugger and we tend not to use it in code.

There are usually alternatives that you could use in code like `Value->print(errs());`...

When I'm done, I look to see if I can rework this properly and submit a pull request.

Any advice on the patches?

S.

[Dmitry Babokin]

Steve,

Sorry for slow responses, I'm on vacation, so checking my mail not frequently.

1. You need to apply only patches starting with LLVM number that you build (i.e. only 5_0_* patches). Usually we report the bugs to LLVM community and they are fixed in later versions, but they may be late for already release versions.

2. Your analysis is correct, LLVM removed dump() from release version in LLVM 5.0. We use it for debugging. If you look at our build scripts (alloy.py), you'll find the following function, which deals with it:

# ISPC uses LLVM dumps for debug output, so build correctly it requires these functions to be

# present in LLVM libraries. In LLVM 5.0 they are not there by default and require explicit enabling.

# In later version this functionality is triggered by enabling assertions.

def get_llvm_enable_dump_switch(version_LLVM):

    if version_LLVM in ["3_2", "3_3", "3_4", "3_5", "3_6", "3_7", "3_8", "3_9", "4_0"]:

        return ""

    elif version_LLVM == "5_0":

        return " -DCMAKE_C_FLAGS=-DLLVM_ENABLE_DUMP -DCMAKE_CXX_FLAGS=-DLLVM_ENABLE_DUMP "

    else:

        return " -DLLVM_ENABLE_DUMP=ON "

So you may use the same approach (these are CMake switches). Or you may just use our build scripts.

For the pull request with your changes - I'm not sure if specifying triple for cross-OS compilation makes sense if it's not universally usable and I'm not sure if we can make it universal. But submitting a how-to to our wiki is definitely would be very useful, as cross compilation questions pop up regularly.

Dmitry.

--
You received this message because you are subscribed to the Google Groups "Intel SPMD Program Compiler Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ispc-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Hill]

Hi Dmitry,

My apologies for interrupting your vacation!

I agree that my overall changes are not likely to be useful - I was thinking of a pull request that replaces the use of dump() so that the special build of LLVM for v5.0 and later can be removed. Let me know what you think.

I can certainly look at starting a wiki page on the subject of cross compilation too once I've tested that it is working properly (I've got a build that looks to be producing a Linux object file but, beyond the 'file' command giving promising output, I've not confirmed that it is good...)

Thanks for your help,

S.

[Dmitry Babokin]

Steve,

I prefer to keep dump() in the source, without this call [--debug-phase=<value>] switch is not possible. And it's very helpful for debugging compiler bugs. Special LLVM build should not be a big deal, as it's almost always need to be patched version of LLVM. So adding extra CMake flag seems to be not an issue.

Dmitry.

--