Build instructions/scripts need to be updated. Unable to build.

[mratsim]

I tried to follow instructions on an up-to-date archlinux distro with GCC 8.3.0 and Clang/LLVM 8.0.0 but had several issues with both LLVM and Halide and had to give up trying Tiramisu in the end.

Note that I can successfully build Halide from source. My last build was as of Feb 9 (https://github.com/halide/Halide/commits/d02247b3021549fde4bec8e600dced90f5d9a87c).

Build

I tried to use the install submodule script at https://github.com/Tiramisu-Compiler/tiramisu/blob/2ee529439fbfccf82f7351ee2e3c01f10387af26/utils/scripts/install_submodules.sh

LLVM

It fails for LLVM after reaching 100%.

[100%] Built target libclang
[100%] Built target c-arcmt-test
[100%] Built target c-index-test
In file included from /home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:20,
                 from /home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/llvm/tools/lli/lli.cpp:22:
/home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/llvm/include/llvm/CodeGen/SchedulerRegistry.h: In constructor ‘llvm::RegisterScheduler::RegisterScheduler(const char*, const char*, llvm::RegisterScheduler::FunctionPassCtor)’:
/home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/llvm/include/llvm/CodeGen/SchedulerRegistry.h:40:52: warning: cast between incompatible function types from ‘llvm::RegisterScheduler::FunctionPassCtor’ {aka ‘llvm::ScheduleDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)’} to ‘llvm::MachinePassCtor’ {aka ‘void* (*)()’} [-Wcast-function-type]
   : MachinePassRegistryNode(N, D, (MachinePassCtor)C)
                                                    ^
In file included from /home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/llvm/tools/lli/lli.cpp:30:
/home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/llvm/include/llvm/ExecutionEngine/Orc/OrcRemoteTargetClient.h: In member function ‘llvm::Expected<std::vector<char> > llvm::orc::remote::OrcRemoteTargetClient<ChannelT>::readMem(char*, llvm::JITTargetAddress, uint64_t)’:
/home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/llvm/include/llvm/ExecutionEngine/Orc/OrcRemoteTargetClient.h:722:26: error: could not convert ‘((llvm::orc::remote::OrcRemoteTargetClient<ChannelT>*)this)->callB<llvm::orc::remote::OrcRemoteTargetRPCAPI::ReadMem>(Src, Size)’ from ‘Expected<vector<unsigned char,allocator<unsigned char>>>’ to ‘Expected<vector<char,allocator<char>>>’
     return callB<ReadMem>(Src, Size);

Halide

The script launches the default compiler, GCC 8 on my machine (note that it works for current master branch Halide). But GCC 8 brought a lots of new warnings that needs to be ignored with:
-Wno-stringop-truncation (/home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/Halide/src/Introspection.cpp:36:12: error: ‘char* strncpy(char*, const char*, size_t)’ specified bound 2048 equals destination size [-Werror=stringop-truncation])
-Wno-catch-value (some polymorphic exception caught by value)
-Wno-format (/home/beta/Programming/DSL_Compilers_for_Tensors/tiramisu/3rdParty/Halide/test/correctness/extern_producer.cpp:47:12: error: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘int64_t’ {aka ‘long int’} [-Werror=format=])
-fpermissive

It would be good to force usage of the Clang 5.0 if that is the only supported one.

Object files

This part of Halide Makefile is deleting the objects that are supposed to be put in the static lib and the make command fails with file not found: https://github.com/jrayzero/Halide/blob/0e2cac7a2e3982d1a51d82932b185f75af05f4c2/Makefile#L670-L697

$(BUILD_DIR)/llvm_objects/list: $(OBJECTS) $(INITIAL_MODULES)
	# Determine the relevant object files from llvm with a dummy
	# compilation. Passing -t to the linker gets it to list which
	# object files in which archives it uses to resolve
	# symbols. We only care about the libLLVM ones.
	@mkdir -p $(@D)
	$(CXX) -o /dev/null -shared $(OBJECTS) $(INITIAL_MODULES) -Wl,-t $(LLVM_STATIC_LIBS) $(COMMON_LD_FLAGS) | egrep "libLLVM" > $(BUILD_DIR)/llvm_objects/list.new
	# if the list has changed since the previous build, or there
	# is no list from a previous build, then delete any old object
	# files and re-extract the required object files
	cd $(BUILD_DIR)/llvm_objects; \
	if cmp -s list.new list; \
	then \
	echo "No changes in LLVM deps"; \
	touch list; \
	else \
	rm -f llvm_*.o*; \
	cat list.new | sed = | sed "N;s/[()]/ /g;s/\n /\n/;s/\([0-9]*\)\n\([^ ]*\) \([^ ]*\)/ar x \2 \3; mv \3 llvm_\1_\3/" | bash -; \
	mv list.new list; \
	fi

$(LIB_DIR)/libHalide.a: $(OBJECTS) $(INITIAL_MODULES) $(BUILD_DIR)/llvm_objects/list
	# Archive together all the halide and llvm object files
	@mkdir -p $(@D)
	@rm -f $(LIB_DIR)/libHalide.a
	# ar breaks on MinGW with all objects at the same time.
	echo $(OBJECTS) $(INITIAL_MODULES) $(BUILD_DIR)/llvm_objects/llvm_*.o* | xargs -n200 ar q $(LIB_DIR)/libHalide.a
	ranlib $(LIB_DIR)/libHalide.a

LLVMHeaders

When building Halide it doesn't search the LLVM Headers in their proper place and I had to explicitly include 3rdParty/llvm/include

CuDNN variable

There is a CUDNN_LOCATION variable here

tiramisu/configure.cmake

Line 19 in 2ee5294

set(CUDNN_LOCATION /data/scratch/akkas/cudnn7)

but during build I had a warning that CUDNN_LIBRARIES was not set.

Looking into this code:

tiramisu/CMakeLists.txt

Lines 41 to 42 in 11395ca

	find_library(CUDNN_LIBRARIES cudnn PATHS ${CUDNN_LOCATION}/lib64 NO_DEFAULT_PATH)
	set(CUDNN_INCLUDE_DIRECTORY ${CUDNN_LOCATION}/include)

either CUDNN_LOCATION should be changed to LIB/INCLUDE similar to ISL and Halide:

tiramisu/configure.cmake

Lines 40 to 46 in 2ee5294

	# ISL paths
	set(ISL_INCLUDE_DIRECTORY "3rdParty/isl/build/include/")
	set(ISL_LIB_DIRECTORY "3rdParty/isl/build/lib/")
	# Halide Paths
	set(HALIDE_SOURCE_DIRECTORY "3rdParty/Halide")
	set(HALIDE_LIB_DIRECTORY "3rdParty/Halide/lib")

or CUDNN_LOCATION description Change with the cudnn library location should be made more clear that it's the directory parent to lib64/libcudnn.so and include/cudnn.h as naively people will set it to /usr/lib or /usr/lib64 instead of /usr

[rbaghdadi]

Hi @mratsim ,

I'm looking into this. It looks like there is a conflict between the Halide that you are using, LLVM and the C++ standard library. The problem might be different but the following links might help:

halide/Halide#3290

halide/Halide#2532

halide/Halide#1243

I'm trying to make Tiramisu work with the latest LLVM/Halide and that should help in solving this problem. I will let you know how things go.

[philomath213]

I followed the INSTALL instructions to build Tiramisu, but things didn't go as expected.

Docker Image
I tried to build a docker image for Tiramisu based on ubuntu:18.04
I managed to build the dependencies ISL, Clang/LLVM and Halide on my own, but Tiramisu build failed
I tried to build it with the these dependencies version:

• ISL 0.22, Clang/LLVM 5, Halide release_2018_02_15
• ISL 0.22, Clang/LLVM 8, Halide release_2019_08_27

PS:
I noticed that the script utils/scripts/install_submodules.sh use "tiramisu_64_bit" branch to build Halide, but I that branch doesn't exist in current Halide repository.
is there any special fork of Halide that works with Tiramisu?

[mratsim]

Yes, it's from a fork here: https://github.com/jrayzero/Halide/tree/tiramisu_64_bit

Note that LLVM now lives on Github so submoduling may be easier: https://github.com/llvm/llvm-project

[lapnd]

Hi,
the link https://github.com/jrayzero/Halide/tree/tiramisu_64_bit is dead now.
Can you please help to update the build?

[rbaghdadi]

You can use the original Halide. No need to use that specific version of Halide.

You can look at the installation script: https://github.com/Tiramisu-Compiler/tiramisu/blob/master/utils/scripts/install_submodules.sh

Disable the area of the script that installs that specific version of Halide, and then install your own Halide form the Halide main repo, and continue the remaining steps.

[lapnd]

Thank you @rbaghdadi