Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable LLVM NVPTX back-end #19323

Merged
merged 1 commit into from
Dec 22, 2016
Merged

Enable LLVM NVPTX back-end #19323

merged 1 commit into from
Dec 22, 2016

Conversation

maleadt
Copy link
Member

@maleadt maleadt commented Nov 14, 2016

(Assumed) non-controversial parts of #19302, enables the LLVM NVPTX back-end (1 MB, 3% file size increase for libLLVM) and adds some crucial patches related to JuliaGPU/CUDAnative.jl#13 (all of them merged already):

  • D9168: segfault in LLVM
  • D24300: adds lowering for some intrinsics
  • D23597: dependency of D24300

@@ -481,6 +485,12 @@ $(eval $(call LLVM_PATCH,llvm-arm-fix-prel31))
$(eval $(call LLVM_PATCH,llvm-D25865-cmakeshlib))
endif # LLVM_VER

ifeq ($(LLVM_VER_SHORT),3.9)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this separate from the above list?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put it there in my branch to avoid merge conflicts, will change.

@@ -78,7 +78,11 @@ LLVM_CFLAGS += $(CFLAGS)
LLVM_CXXFLAGS += $(CXXFLAGS)
LLVM_CPPFLAGS += $(CPPFLAGS)
LLVM_LDFLAGS += $(LDFLAGS)
LLVM_TARGETS := host
ifeq ($(LLVM_USE_CMAKE),1)
LLVM_TARGETS := host;NVPTX
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't usually indent this kind of thing in makefiles

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough.

@tkelman
Copy link
Contributor

tkelman commented Nov 14, 2016

will need to be tested on the buildbots to make sure it builds everywhere, if it's going to be enabled on all platforms by default

@maleadt maleadt force-pushed the tb/llvm_nvptx branch 2 times, most recently from b103efd to ef5b0e2 Compare November 15, 2016 16:53
@maleadt
Copy link
Member Author

maleadt commented Nov 16, 2016

Travis is happy. Any other configurations to manually test this on?

@tkelman
Copy link
Contributor

tkelman commented Nov 16, 2016

all of the buildbots

@maleadt
Copy link
Member Author

maleadt commented Nov 16, 2016

Right, but those only run on master and I don't have an account to request builds on this PR's branch.
So how do I make them run?

@ViralBShah
Copy link
Member

Perhaps @tkelman or @staticfloat can share the creds with you for kicking off builds.

@tkelman
Copy link
Contributor

tkelman commented Nov 17, 2016

I triggered a set of builds of this branch, they're running now. Something unrelated is wrong on the mac buildbot, it's having python issues with building the docs.

@maleadt
Copy link
Member Author

maleadt commented Nov 17, 2016

The windows bots are acting up:

llvm-3.7.1/lib/Target/NVPTX/TargetInfo/NVPTXTargetInfo.cpp:10:19: fatal error: NVPTX.h: No such file or directory
 #include "NVPTX.h"
                   ^
compilation terminated.

Not sure how that could happen, it seems like LLVM 3.7 doesn't build if the NVPTX target is enabled?
I'll have a closer look.

@ViralBShah
Copy link
Member

I guess things would be easier if were already using llvm 3.9.

@ViralBShah
Copy link
Member

ViralBShah commented Dec 19, 2016

It does seem that llvm 3.9 is awfully close - but are we going to move to it for 0.6? If not, since it is late in the cycle, should we merge this?

Having CUDANative.jl work with Julia 0.6 out of the box would be a nice feature to add, like we did ARM and POWER for 0.5.

@ViralBShah ViralBShah added domain:gpu Affects running Julia on a GPU compiler:codegen Generation of LLVM IR and native code labels Dec 19, 2016
@tkelman
Copy link
Contributor

tkelman commented Dec 19, 2016

LLVM 3.7 doesn't build if the NVPTX target is enabled

that's a no, we shouldn't merge this without upgrading llvm

@tkelman
Copy link
Contributor

tkelman commented Dec 22, 2016

Actually we should probably get the LLVM patches here onto master before we upgrade, so they go into the homebrew and appveyor binaries (I'll need to rebuild the latter) and the CI build matches what you get in a source build.

@maleadt
Copy link
Member Author

maleadt commented Dec 22, 2016

OK, I can split those off. I just rebased this branch on top of your LLVM 3.9 update PR to first see if NVPTX will build correctly on Windows.

@tkelman
Copy link
Contributor

tkelman commented Dec 22, 2016

Sure, worth testing. Do you have a login to the buildbots, or need me to fire that off? (edit: running now)

@maleadt
Copy link
Member Author

maleadt commented Dec 22, 2016

Shouldn't we also include the NVPTX back-end in the homebrew/appveyor binaries, if we want to ship that as part of Julia 0.6 @ LLVM 3.9? To do so, we could shield the LLVM_TARGETS += NVPTX behind a check against 3.9+ and merge this PR (if it builds correctly on all platforms).

That said, unless I still manage to create a PR for packaging an additional 'dev tools' tarball (with llvm-config, include/llvm/*, etc), users will have to build from source anyway.

@tkelman
Copy link
Contributor

tkelman commented Dec 22, 2016

users will have to build from source anyway

Sounds like it wouldn't add all that much value to turn on by default as long as this is the case?

@maleadt
Copy link
Member Author

maleadt commented Dec 22, 2016

Ah yes, this will fail until JuliaCI/julia-buildbot#54 is resolved of course.

-- Configuring incomplete, errors occurred!
CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
  CMake 3.4.3 or higher is required.  You are running version 3.3.2

@ViralBShah
Copy link
Member

Yes, if it builds on all platforms, this is a great idea.

@ViralBShah ViralBShah added this to the 0.6.0 milestone Dec 22, 2016
@tkelman
Copy link
Contributor

tkelman commented Dec 22, 2016

we could shield the LLVM_TARGETS += NVPTX behind a check against 3.9+ and merge this PR (if it builds correctly on all platforms).

Let's do that then - just your commit, modified to only build the nvptx backend when using llvm >= 3.9. This branch seems to be working everywhere, but let's rearrange it so we can merge it independently. I'll need to rebase #19678 on top of #19681 anyway, and it'll have to wait for the homebrew formula and some benchmarking.

@maleadt maleadt force-pushed the tb/llvm_nvptx branch 2 times, most recently from 8358eee to 0a55584 Compare December 22, 2016 14:10
@tkelman
Copy link
Contributor

tkelman commented Dec 22, 2016

just your commit

Take mine out - can't merge this while 7851f77 is in here all set now

LLVM_TARGET_STRING := $(subst $(SPACE),;,$(LLVM_TARGETS))
else
COMMA := ,
LLVM_TARGET_STRING := $(subst $(SPACE),$(COMMA),$(LLVM_TARGETS))
Copy link
Contributor

@tkelman tkelman Dec 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to worry about this case? it's not possible to use configure with 3.9 or newer, so I'd simplify this as something like

ifeq ($(LLVM_VER_SHORT),$(filter $(LLVM_VER_SHORT),3.3 3.4 3.5 3.6 3.7 3.8))
LLVM_TARGET_STRING := host
else
LLVM_TARGET_STRING := host;NVPTX
endif

if that works

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured I'd keep it a little more extensible, but sure that works too. I'll update the PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

people can always override LLVM_TARGETS (or LLVM_TARGET_STRING or whatever) in their Make.user, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty much, yeah.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then I guess we could keep it called LLVM_TARGETS just for minimal disruption to anyone who might already be doing this?

Use of the NVPTX back-end is only tested on LLVM 3.9,
in combination with the CUDAnative.jl package.
@tkelman tkelman merged commit 370886c into master Dec 22, 2016
@tkelman tkelman deleted the tb/llvm_nvptx branch December 22, 2016 15:44
@@ -73,17 +73,22 @@ LLVM_LIBCXX_TAR:=$(SRCDIR)/srccache/libcxx-$(LLVM_TAR_EXT)
endif
endif # LLVM_VER != svn

# Figure out which targets to build
ifeq ($(LLVM_VER_SHORT),$(filter $(LLVM_VER_SHORT),3.3 3.4 3.5 3.6 3.7 3.8))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this condition evaluate to true when LLVM_VER_SHORT is svn ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It shouldn't.

Copy link
Contributor

@singam-sanjay singam-sanjay Mar 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you enable the NVPTX back-end for svn builds ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be enabled since the false branch enables nvptx backend............

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:codegen Generation of LLVM IR and native code domain:gpu Affects running Julia on a GPU
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants