MixmasterFresh / rust-on-gpu

A fork of the Rust Language for experimenting with GPU support.
https://www.rust-lang.org
Other
5 stars 0 forks source link

initial support for PTX generation #3

Closed japaric closed 8 years ago

japaric commented 8 years ago

see commit messages for details

japaric commented 8 years ago

@TheAustinSeven how do you want to go about merging this? Want me to add a smoke test that converts a mostly empty Rust file into a PTX file and checks that header is there (.version and .address_size directives are there)?

There are a few issues to solve in the PTX backend but I think those can be addressed in follow up PRs. I can open GH issues for those.

japaric commented 8 years ago

I think Travis failed because it's using a cached version of LLVM that wasn't built with the PTX backend enabled. Clearing the LLVM cache should fix it.

MixmasterFresh commented 8 years ago

I don't think thats it. Currently no caching is taking place from build to build, so the travis is running a separate apt-get every time. I'm looking into it...

What version of LLVM are you using?

japaric commented 8 years ago

Ah the Travis build is using a packaged llvm. I didn't noticed. That could be the problem; looks like the packaged llvm was built without the PTX backend enabled. There's a command to check which backends are enabled but I don't remember right now.

What version of LLVM are you using?

I'm building from source. I modified the build system so it now builds llvm with the PTX backend enabled. I should also mention that I only modified the "rustbuild" build system and not the "old makefile based" build system. This means that building without passing --enable-rustbuild to configure will probably fail to build as well.

japaric commented 8 years ago

There's a command to check which backends are enabled but I don't remember right now.

See llc -version -> Supported targets. nvptx should be there.

MixmasterFresh commented 8 years ago

On line 1626 of configure there is a statement: LLVM_TARGETS="--enable-targets=x86,x86_64,arm,aarch64,mips,powerpc"

I would start by adding NVPTX there, and seeing if that helps solve the problems. The NVPTX files are included with the LLVM release that the build pulls in, I just think that they aren't getting enabled in configure.

japaric commented 8 years ago

On line 1626 of configure there is a statement:

I've tentatively pushed a commit that does that change but I won't be able to properly test this till tomorrow.

MixmasterFresh commented 8 years ago

As for testing, I think as long as there is a test that trys to compile valid rust into PTX, and ensures that it doesn't break, that should be fine for now.

MixmasterFresh commented 8 years ago

There is the same deal on line 299 of mk/main.mk with the line: LLVM_OPTIONAL_COMPONENTS=x86 arm aarch64 mips powerpc pnacl

MixmasterFresh commented 8 years ago

The tests passed :tada: . I am inclined to merge this in without tests, and add those in in later updates, so that anyone who wants to start playing around with this can do so. Let me know if you want to merge it as is, and we can do that.

japaric commented 8 years ago

:+1: to merging as is. But I guess the tests now have to run again because master was rebased(?). (Homu/bors would take care of detecting such scenarios. FWIW, here's how to set a homu instance on Heroku)

I'm going to go ahead and open some follow-up issues.

MixmasterFresh commented 8 years ago

I think that setting up a homu instance in the future may be helpful, but until then I think it will be sufficient to just watch the build after the merge. I don't expect we will have a terribly high rate of PR's in the near future and if we do, then Homu will make more sense.