LLVM backend: on Windows use clang instead of llc

llc.exe is not included with the LLVM official Windows binaries. clang can
compile .ll files too but requires different args.

This behaviour is gated by __FB_WIN32__ because there doesn't seem to be an
existing way to check whether a tool exists. It would be better to fallback to
clang only if llc doesn't exist (for example I see it is missing from at least
some Android NDK toolchains too).

Tested on Linux, not Windows.

changelog.txt

@@ -108,6 +108,7 @@ Version 1.08.0
 - sf.net #928: Wrong sign / type when printing BYTE values on arm/aarch64
 - various HANDLE_WM_*, FORWARD_WM_* macros in win/windowsx.bi were broken
 - gcc backend was trying to pass single types to double typed built-ins
+- llvm backend on Windows invokes clang.exe instead of llc.exe (which usually doesn't exist)
 
 
 Version 1.07.0

src/compiler/fbc.bas

@@ -118,6 +118,7 @@ enum
 	FBCTOOL_LD
 	FBCTOOL_GCC
 	FBCTOOL_LLC
+	FBCTOOL_CLANG
 	FBCTOOL_DLLTOOL
 	FBCTOOL_GORC
 	FBCTOOL_WINDRES
@@ -132,7 +133,7 @@ end enum
 
 static shared as zstring * 16 toolnames(0 to FBCTOOL__COUNT-1) = _
 { _
-	"as", "ar", "ld", "gcc", "llc", "dlltool", "GoRC", "windres", "cxbe", "dxe3gen", _
+	"as", "ar", "ld", "gcc", "llc", "clang", "dlltool", "GoRC", "windres", "cxbe", "dxe3gen", _
 	"emcc", _
 	"emar", _
 	"emcc", _
@@ -2954,6 +2955,11 @@ private function hCompileXpm( ) as integer
 	function = TRUE
 end function
 
+#if __FB_WIN32__
+	'' LLVM official Windows binary distributions lack llc.exe, use clang instead
+	#define NO_LLC
+#endif
+
 private function hCompileStage2Module( byval module as FBCIOFILE ptr ) as integer
 	dim as string ln, asmfile
 
@@ -3057,13 +3063,34 @@ private function hCompileStage2Module( byval module as FBCIOFILE ptr ) as intege
 		end select
 
 	case FB_BACKEND_LLVM
+		#ifdef NO_LLC
+			ln += "-S "
+			'' Silence "overriding the module target triple" warning. Maybe warning
+			'' that the target should be declared in the .ll instead.
+			ln += "-Wno-override-module "
+			'' Tell clang we're using system as, so don't use extensions in the asm
+			ln += "-no-integrated-as "
+		#endif
+
 		select case( fbGetCpuFamily( ) )
 		case FB_CPUFAMILY_X86
-			ln += "-march=x86 "
+			#ifdef NO_LLC
+				ln += "--target=i686 "
+			#else
+				ln += "-march=x86 "
+			#endif
 		case FB_CPUFAMILY_X86_64
-			ln += "-march=x86-64 "
+			#ifdef NO_LLC
+				ln += "--target=x86_64 "
+			#else
+				ln += "-march=x86-64 "
+			#endif
 		case FB_CPUFAMILY_ARM
-			ln += "-march=arm "
+			#ifdef NO_LLC
+				ln += "--target=armv7a "
+			#else
+				ln += "-march=arm "
+			#endif
 		case FB_CPUFAMILY_AARCH64
 			'' From the GCC manual:
 			'' -march=name
@@ -3097,7 +3124,11 @@ private function hCompileStage2Module( byval module as FBCIOFILE ptr ) as intege
 			'' is tuned to perform well across a range of target 
 			'' processors implementing the target architecture.
 
-			ln += "-march=armv8-a "
+			#ifdef NO_LLC
+				ln += "--target=armv8a "
+			#else
+				ln += "-march=armv8-a "
+			#endif
 		end select
 
 		if( fbGetOption( FB_COMPOPT_PIC ) ) then
@@ -3109,7 +3140,11 @@ private function hCompileStage2Module( byval module as FBCIOFILE ptr ) as intege
 		select case( fbGetCpuFamily( ) )
 		case FB_CPUFAMILY_X86, FB_CPUFAMILY_X86_64
 			if( fbGetOption( FB_COMPOPT_ASMSYNTAX ) = FB_ASMSYNTAX_INTEL ) then
-				ln += "--x86-asm-syntax=intel "
+				#ifdef NO_LLC
+					ln += "-masm=intel "
+				#else
+					ln += "--x86-asm-syntax=intel "
+				#endif
 			end if
 		end select
 
@@ -3127,7 +3162,12 @@ private function hCompileStage2Module( byval module as FBCIOFILE ptr ) as intege
 		end if
 		function = fbcRunBin( "compiling C", gcc, ln )
 	case FB_BACKEND_LLVM
-		function = fbcRunBin( "compiling LLVM IR", FBCTOOL_LLC, ln )
+		#ifdef NO_LLC
+			const compiler = FBCTOOL_CLANG
+		#else
+			const compiler = FBCTOOL_LLC
+		#endif
+		function = fbcRunBin( "compiling LLVM IR", compiler, ln )
 	end select
 end function