commit | e670523ddd228e57304a84653c4855dae092983b | [log] [download] |
---|---|---|
author | Cory Bloor <Cordell.Bloor@amd.com> | Mon Oct 10 20:09:27 2022 -0600 |
committer | GitHub <noreply@github.com> | Mon Oct 10 21:09:27 2022 -0500 |
tree | 8019da5b7c8f47a5f34cf561a9f321ad2e2f7d4b | |
parent | aa4db15ea757b9a6f756c4e54fb9dee62801b8c2 [diff] |
Add ROCm Clang and HIP to CUDA (#4097) * Add ROCm Clang and HIP to CUDA * Always include hip/hip_runtime.h The need to include <hip/hip_runtime.h> and/or <hip/hip_runtime_api.h> in HIP code before using HIP features is one big difference between HIP and CUDA. Manually adding it to the command-line here is not ideal, but the alternative is that the CUDA sample code will be broken by default when a HIP compiler is selected. This is perhaps an argument for making HIP a separate language in compiler explorer, but there's pros and cons to both approaches. I'm not sure which approach is best, but the existing HIP support that I built upon was based on using CUDA as the language. * Add hip-amd to CUDA libs * Fix id collsion and drop --offload-arch * Drop trunk compilers The nightly builds of ROCm Clang and vanilla Clang lack both device libraries and the HIP library. Their ability to compile HIP code is very limited without those, to the extent that they will not be able to build the example code without changes. I suspect that it's possible to fix those issues, but it may be less confusing to drop them from the compiler list until they are fully functional. * Add self to CONTRIBUTORS.md * Restore hiptrunk compiler Put the hiptrunk compiler back how it was, so that the addition of the HIP libraries is a purely additive change in functionality. However, mark hiptrunk as hidden so that it is not visible by default. Co-authored-by: Patrick Quist <partouf@gmail.com>
Compiler Explorer is an interactive compiler exploration website. Edit code in C, C++, C#, F#, Rust, Go, D, Haskell, Swift, Pascal, ispc, Python, Java or in any of the other 30+ supported languages, and see how that code looks after being compiled in real time. Multiple compilers are supported for each language, many different tools and visualisations are available, and the UI layout is configurable (thanks to GoldenLayout).
Try out at godbolt.org, or run your own local instance.
Compiler Explorer follows a Code of Conduct which aims to foster an open and welcoming environment.
Compiler Explorer was started in 2012 to show how C++ constructs translated to assembly code. It started out as a tmux
session with vi
running in one pane and watch gcc -S foo.cc -o -
running in the other.
Since then, it has become a public website serving around 3,000,000 compilations per week.
You can financially support this project on Patreon, GitHub, Paypal, or by buying cool gear on the Compiler Explorer store.
There is now a FAQ section in the repository wiki. If your question is not present, please contact us as described below, so we can help you. If you find that the FAQ is lacking some important point, please free to contribute to it and/or ask us to clarify it.
There are a number of videos that showcase some features of Compiler Explorer:
A Road map is available which gives a little insight into the future plans for Compiler Explorer.
Compiler Explorer is written in Node.js.
Assuming you have a compatible version of node
installed, on Linux simply running make
ought to get you up and running with an Explorer running on port 10240 on your local machine: http://localhost:10240/. If this doesn't work for you, please contact us, as we consider it important you can quickly and easily get running. Currently, Compiler Explorer requires node
16 (LTS version) installed, either on the path or at NODE_DIR
(an environment variable or make
parameter).
Running with make EXTRA_ARGS='--language LANG'
will allow you to load LANG
exclusively, where LANG
is one for the language ids/aliases defined in lib/languages.ts
. For example, to only run Compiler Explorer with C++ support, you'd run make EXTRA_ARGS='--language c++'
. The Makefile
will automatically install all the third party libraries needed to run; using npm
to install server-side and client side components.
For development, we suggest using make dev
to enable some useful features, such as automatic reloading on file changes and shorter startup times.
You can also use npm run dev
to run if make dev
doesn't work on your machine.
Some languages need extra tools to demangle them, e.g. rust
, d
, or haskell
. Such tools are kept separately in the tools repo.
Configuring compiler explorer is achieved via configuration files in the etc/config
directory. Values are key=value
. Options in a {type}.local.properties
file (where {type}
is c++
or similar) override anything in the {type}.defaults.properties
file. There is a .gitignore
file to ignore *.local.*
files, so these won‘t be checked into git, and you won’t find yourself fighting with updated versions when you git pull
. For more information see Adding a Compiler.
Check CONTRIBUTING.md for detailed information about how you can contribute to Compiler Explorer, and the docs folder for specific details regarding various things you might want to do, such as how to add new compilers or languages to the site.
If you want to point it at your own GCC or similar binaries, either edit the etc/config/LANG.defaults.properties
or else make a new one with the name LANG.local.properties
, substituting LANG
as needed. *.local.properties
files have the highest priority when loading properties.
When running in a corporate setting the URL shortening service can be replaced by an internal one if the default storage driver isn't appropriate for your environment. To do this, add a new module in lib/shortener/myservice.js
and set the urlShortenService
variable in configuration. This module should export a single function, see the tinyurl module for an example.
There's a simple restful API that can be used to do compiles to asm and to list compilers.
You can find the API documentation here.
We run a Compiler Explorer Discord, which is a place to discuss using or developing Compiler Explorer. We also have a presence on the cpplang Slack channel #compiler_explorer
and we have a public mailing list.
There's a development channel on the discord, and also a development mailing list.
Feel free to raise an issue on github or email Matt directly for more help.
Compiler Explorer is maintained by the awesome people listed in the AUTHORS file.
We would like to thank the contributors listed in the CONTRIBUTORS file, who have helped shape Compiler Explorer.
We would also like to specially thank these people for their contributions to Compiler Explorer:
A number of amazing sponsors, both individuals and companies, have helped fund and promote Compiler Explorer.