## What
Adds support for seeing Yul (Solidity IR) as intermediate output when
compiling Solidity.
This PR also enables that view for the Resolc compiler.
### Main Additions
- [x] Support viewing Yul in a supplementary view
- Solidity compilers can enable this by setting
`this.compiler.supportsYulView = true` in the compiler's constructor
- If custom processing of the Yul output or the Yul output filename is
needed, the compiler can override `processYulOutput()` or
`getYulOutputFilename()`
- [x] Enable the Yul view for Resolc
- [x] Implement a Yul backend option for filtering out debug info from
the output
### Notes
Source mappings are currently not handled for Yul -> Solidity.
## Overall Usage
### Steps
* Choose Solidity as the language
* Choose a Resolc compiler
* View intermediate results:
* Yul
* (Hide/show debug info by toggling "Hide Debug Info" in the Yul view
filters)
## Screenshots
<img width="1502" height="903" alt="ce-yul-view"
src="https://github.com/user-attachments/assets/ccc897e2-cd8d-4c33-962c-522d60b63134"
/>
<img width="1405" height="474" alt="Clojure in Compiler Explorer 2"
src="https://github.com/user-attachments/assets/76dfed9b-d0eb-4764-b371-9c6023088a50"
/>
With Macro Expansion:
<img width="1642" height="594" alt="image"
src="https://github.com/user-attachments/assets/8b511af9-3617-426e-868d-5a99e5db5756"
/>
TODO
- [x] Language configuration
- [x] Compile via wrapper
- Inject namespace if necessary to simplify minimal code sample
- Parse Unix style command line parameters into compiler bindings
- Place file in path according to namespace
- [x] Install some versions of Clojure [PR
here](https://github.com/compiler-explorer/infra/pull/1849)
- [x] Macroexpansion view (modeled on Rust macro expansion view)
- [x] Filter out command line options that would break wrapper operation
- [x] ~~Parse `--help` output to a list of options~~ Reverted because
not applicable.
- [x] Short form compiler options
- [x] Support Clojure compiler settings via env var, like
`JAVA_OPTS=-Dclojure.compiler.direct-linking=true
-Dclojure.compiler.elide-meta=[:doc,:file]`
NOT DOING
- [x] ~~Support loading dependencies~~ Non-trivial enhancement. Not
necessary for initial release.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
## What
Adds [Revive's Resolc](https://github.com/paritytech/revive) compiler
for compiling Solidity and Yul (Solidity IR) to RISC-V and PolkaVM
assembly.
### Main Additions
- [x] Implement new `ResolcCompiler`
- [x] Implement Yul language definition and config for Monaco
- [x] Add Resolc as a compiler for the Solidity and Yul languages
- The `ResolcCompiler` handles both kinds of language input
- [x] Implement initial `PolkaVMAsmParser` (no source mappings)
- [x] Enable viewing LLVM IR in a supplementary view
- [x] Implement a new LLVM IR backend option for toggling between
optimized and unoptimized ll
- Affects non-resolc files ([see
commit](606bab9a59))
- Disabled by default
- (Enable by setting `this.compiler.supportsIrViewOptToggleOption =
true` in a compiler's constructor)
- The compiler's `getIrOutputFilename()` will receive the LLVM IR
backend options
### CE Infra
Accompanying CE Infra PR:
https://github.com/compiler-explorer/infra/pull/1855
## Overall Usage
### Steps
(See screenshots)
* Choose between two input languages:
* Solidity
* Yul (Solidity IR)
* Choose a Resolc compiler
* View assembly:
* PolkaVM assembly (if enabling "Compile to binary")
* RISC-V (64 bits) assembly
* View intermediate results:
* Optimized LLVM IR (if enabling "Show Optimized" in the LLVM IR view)
* Unoptimized LLVM IR
### Notes
Source mappings currently only exist between:
- Yul and RISC-V
- Yul and LLVM-IR
## Screenshots
<img width="1502" height="903" alt="CE Yul RISC-V LLVM IR"
src="https://github.com/user-attachments/assets/7503b9b5-0f2c-4ddf-9405-669e4bdcd02d"
/>
<img width="1502" height="903" alt="CE Solidity PolkaVM"
src="https://github.com/user-attachments/assets/eeb51c99-3eaa-4dda-b13c-ac7783e66cb8"
/>
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Close#5530. Infra:
https://github.com/compiler-explorer/infra/pull/1711. Previous work by
@siboehm at #5531
## Summary
This pull request introduces support for the
[Triton](https://github.com/triton-lang/triton) language, a Python-based
DSL for writing highly efficient GPU kernels.
- [x] **New Language Support**: I've added comprehensive support for the
Triton programming language, allowing users to compile and inspect
Triton kernels within Compiler Explorer. (c.f.,
`lib/compilers/triton.ts`)
- [x] **Python Wrapper for Compilation**: A new Python wrapper script
(`triton_wrapper.py`) has been introduced to manage Triton compilation,
patching its behavior to dump compiled kernels and intermediate
representations without requiring actual execution, and consolidating
the output for Compiler Explorer.
- [x] **Device Assembly View**: Enables viewing of generated device
assembly code (e.g., PTX, AMDGCN) and various intermediate
representations (MLIR, LLVM IR) produced by the Triton compiler.
- [x] **MLIR Parsing**: New parsers (`asm-parser-mlir.ts` and
`mlir-pass-dump-parser.ts`) have been added to correctly interpret and
display MLIR assembly and optimization pass dumps, including source
location information.
- [x] **Multi-Version & Multi-Backend Support**: Painstakingly includes
all 8 versions (from 2.2.0 to 3.3.1) of Triton that supports Python
3.12. Supports both CUDA and HIP backend for Triton 3.
## Screenshots
Source and assembly:
<img width="1354" height="789" alt="image"
src="https://github.com/user-attachments/assets/c29650ff-2073-40e0-a9e6-ff8377094b5e"
/>
Device view for MLIR and LLVM IR:
<img width="1402" height="670" alt="image"
src="https://github.com/user-attachments/assets/43dd5c68-ca78-41b1-9865-e97ffe3ef73c"
/>
Opt pipeline viewer:
<img width="1408" height="668" alt="image"
src="https://github.com/user-attachments/assets/429eef8c-aaac-4781-aafa-39ef0ffc7241"
/>
Diff of TTIR in Triton 3.3.1 vs 2.3.0:
<img width="1580" height="726" alt="image"
src="https://github.com/user-attachments/assets/a928c893-dd9a-4c3a-a048-14046e56a14c"
/>
CUDA & HIP:
<img width="1596" height="800" alt="image"
src="https://github.com/user-attachments/assets/c18800c3-cfad-4e5e-96de-ba92c9f236ea"
/>
## Implementation Details (and Notes for Reviewers)
- For Device Assembly View, I Implemented `MlirAsmParser` for parsing
MLIR assembly. Technically MLIR is not an assembly language, but there
is no better choice to make the source line map work w/ device view.
- I Implemented `MlirPassDumpParser` for processing MLIR optimization
pass dumps. I tried to subclass `LlvmPassDumpParser`, but they turn out
to be too different to worth doing it.
- `LlvmPassDumpParser` made some assumptions that do not hold true for
MLIR passed. Some effort is put to make sure that the passes are
properly diff-ed, since some passes can run multiple times and also
sometimes pass can be nested (i.e., some number of `before`s followed by
some number of `after`s)
- A lot of effort is put into `patch_triton` to make sure that the we
only compile the kernel without actually running it, and that needs to
work across all the versions we support.
## Steps to Run Locally
1. Clone https://github.com/ShawnZhong/compiler-explorer-infra.git
2. Install Triton to `/opt/compiler-explorer/triton`:
```sh
$ cd compiler-explorer-infra
$ ./bin/ce_install install triton
$ ls /opt/compiler-explorer/triton
# v2.2.0 v2.3.0 v2.3.1 v3.0.0 v3.1.0 v3.2.0 v3.3.0 v3.3.1
```
3. Clone https://github.com/ShawnZhong/compiler-explorer.git and
checkout branch `triton`
4. Run Compiler Explorer
```sh
make EXTRA_ARGS='--language triton' dev
```
5. Enjoy
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
- latest biome, and fix its configuration
- fixes "static" content to be globally configured too (instead of
per-line)
- fixes issues:
- imports fixed up
- `Date.now()` vs `+new Date()`
- some unused things `_` prefixed
After discussion with the team, turned off the unused parameter warning.
- Removes `rootDirs` so all imports will be relative in the frontend
- Updates (and unifies) imports to be `../types/...` etc instead of
relying on "types" being in the rootDir for the frontend.
- Fixes one type that was being picked up from `lib` in the frontend.
- Adds a precommit hook to check in future
Paves the way to writing _unit_ tests for the frontend for the subset of
the frontend code we can import from `node` (which might be a lot of
it!)
This PR adds support for the Mojo programming language.
Explicitly tested viewing the generated assembly, LLVM IR, and running
the generated executable.
This adds support for the [Sail
language](https://github.com/rems-project/sail) - a DSL for defining
ISAs.
It's not quite ready but I need some help. These are the main remaining
issues:
1. When you "link to binary" it does disassemble the binary properly,
but the syntax highlighting and line numbers are broken.
2. If you try to execute the code without a `function main() -> unit =
...` then it gives this error in the compiler output:
```
Internal Compiler Explorer error: Error: spawn /tmp/compiler-explorer-compiler2025025-31052-c8gern.pf8t/model.c EACCES
at ChildProcess._handle.onexit (node:internal/child_process:285:19)
at onErrorNT (node:internal/child_process:483:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Compiler returned: -1
```
This is weird - it should give a linker with an undefined reference to
`zmain`.
3. Sail compiles to C, and then I added extra steps to compile that to
binary (if you select `Execute the code`), but as you can see I had to
move the binary back over the C file, so in this case `model.c` is
actually an ELF file. It works but that seems very weird. There is a
`getExecutableFilename()` method I could override, but doing that seems
to make it even more confused.
4. I also had to have a fake flag for `binary` because the `filters`
don't seem to get set correctly when passed to `runCompiler()`. E.g.
`buildExecutable()` doesn't pass them at all. Not sure what is going on
there. Seems to work though.
Any help appreciated!
PS: Sail is a cool language. It has lightweight dependent type for
integers and bit vectors, which I haven't demonstrated in the examples
yet, but they're neat.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Resolves#7521.
With this PR, `@...` suffixes are included in the clickable area for
go-to label.
This also affects PowerPC, where `@...` suffixes are a bit more common
(`@ha` and `@l` will also be marked as clickable).
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
This fork provides a rudimentary way of using Coccinelle within Compiler
Explorer.
In the left window one can edit either C or C++ code, and within
preprocessor ifdefs, one can write a semantic patch for Coccinelle.
The right window will display the transformed code.
A coccinelle on infra is not yet done.
Any distribution-based coccinelle would do, for the moment.
If you like it, this close#6999 .
---------
Signed-off-by: Michele Martone <michelemartone@users.sourceforge.net>
Co-authored-by: Patrick Quist <partouf@gmail.com>
Co-authored-by: Mats Jun Larsen <mats@jun.codes>
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Should be pretty self explanatory. I've added a corresponding PR to the
infra repo [here](https://github.com/compiler-explorer/infra/pull/1532)
Please let me know if there is anything I've done incorrectly here!
Thanks
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
- Add initial support for Numba compilation: asm, demangling, execution
Numba wraps Python functions in `Dispatcher` objects. Each dispatcher
contains zero or more compiled argument-type-indexed overloads of its
function. We import the user's code as a module, and emit the code from
all overloads of all dispatchers that the module publicly exposes.
Name mangling is odd in Numba. It uses a similar mangling syntax to C++,
but also encodes non-symbol (`r"[^a-z0-9_]"`) characters as `_%02x`.
This encoding yields valid identifier names, so it is not strictly
invertible. Here, I have hard-coded some replacements to decode some
common cases at the cost of possible clashes with ugly user-defined
names.
Screenshot captured via `make dev EXTRA_ARGS="--debug --language numba"`
## To do
- [x] Answer questions of #5591.
- [x] Acquire a python environment.
- [ ] Automatically run the python test?
Locally, I have installed a virtual environment with python 3.12.3 with
```shell
path/to/python -m venv venv_numba
path/to/venv_numba/bin/python -m pip install numba==0.61.0 scipy>=0.16
```
and configured its use with
```properties
# compiler-explorer/etc/config/numba.local.properties
compilers=&numba
defaultCompiler=numba_0_61_0
group.numba.compilers=numba_0_61_0
group.numba.baseName=Numba
compiler.numba_0_61_0.exe=/path/to/python3.13
compiler.numba_0_61_0.semver=0.61.0
```
I run this python-side test file with
```python
path/to/venv_numba/bin/python -m unittest etc/scripts/test_numba_wrapper.py
```
---------
Co-authored-by: Mats Jun Larsen <mats@jun.codes>
[ORCA/C](https://github.com/byteworksinc/ORCA-C) is a C compiler that
natively runs on and targets the Apple IIGS. ORCA/C and the programs it
generates can be run on modern Linux systems by using an emulation tool
called [Golden Gate](https://goldengate.gitlab.io).
This adds support for ORCA/C (run via Golden Gate) in Compiler Explorer.
It uses its own assembly format and objdumper (provided by Golden Gate),
so support for those is added. An extra configuration option was also
added to support execution via an emulator, bypassing the usual check
that executables can run natively. Asm docs for the WDC 65C816 processor
were also added.
ORCA/C and Golden Gate are not Free Software, but their rights holders
have given permission for them to be used on Compiler Explorer. Tarballs
for them can be supplied privately. See infra PR:
compiler-explorer/infra#1521
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Libraries were being fetched from wrong URL (on startup);
`Fetching remote libraries from
https://godbolt.org:443/api/libraries/c++`
Ended up refactoring a bunch of things to get some unittesting going on
I did not test actual startup and compilation with CE, I might have
broken something. (but @mattgodbolt tested and it looked great)
- Uses strings across the board in the UI part (no functional change
here from before; all state is the same as it was before).
- Sends _arrays_ in the POST, using the same `splitArguments` code as
the backend.
- Backend _still supports_ strings (though doesn't advertise), also
using same `splitArguments`.
- Moves `splitArguments` into common utils, and rephrases to avoid
unnecessary use of underscore and ES2021+ code.
Tested locally:
- with both old and new client code (ran new backend and old webcode to
show sending strings still works)
- with creating and removing tool windows (checked with `ldd` locally)
- with various strings on the client `moo foo "this is bad" #moo` and
even "error" things like `this is "badger` (with a missing close quote).
All works as you'd expect
Happy to break the "move the splitArguments" code into a separate PR if
that'd be easier to review separately.
Fixes#7195
Does some winter cleaning on the site-template stuff :)
1. Migrated away from the custom conf format to plain old yaml
2. Made the images and image files match with the name from the yaml
file. (It's not a problem to have spaces in file paths, nor urls so I
don't see why we shouldn't)
3. Updated the relevant documentation
There is a small breakage in the api response for the meta field. It now
returns `{"screenshot_dimensions":{"width":1000,"height":800}}` which I
believe is a lot more useful than
`{"meta.screenshot_dimensions":"1000x800"}`
Besides, I don't believe this endpoint has any third-party consumers
that rely on the metadata since it's a rarely known feature anyways
This is the first PR in API consistency with more to come:
1. The source API urls have been properly defined with
`/source/:source/list` and `/source/:source/load/:language/:filename`
- These used to be two API endpoints mushed together into one `handle()`
function. They are now separate
- While it may appear from the tests that this is an API breakage,
there's currently no way to have the source API spit out responses for
stuff like `/source/moose/load/Grunkle`.
2. The frontend code calling the list api now has shared types
3. Code has been migrated to `/lib/handlers/api/source.ts`
- I've moved code here, because I would like to separate the stuff
that's under the API and the stuff that isn't (e.g., healthcheck)
- The source endpoint is currently not under /api, but I believe it
makes sense to move it.
4. GitHub is terrible at showing the diff, but the `browser.ts` file has
been removed, since it's never actually used. Our frontend only calls
`/source/builtin/...` and it never had any entries. Besides, the type
used on the frontend for the locally stored stuff is different...
Hello! I'm a big fan of Godbolt and use it regularly to test gas
optimizations in Solidity. However, to this day, there is no support for
Vyper, the second most popular language targeting the EVM, related issue
#4165. We at Statemind.io thought that adding Vyper support would
greatly benefit developers and security researchers, so here is our
attempt to get it working :)
This PR **is not ready** for merging, as `vyper.defaults.properties` and
`vyper.amazon.properties` are not yet defined. I have a few questions to
clarify how to integrate it on the public instance and infrastructure
repository:
Because Vyper compiler is basically a python module, I've found success
in testing multiple versions via separate `venv` environments. In my
local tests `vyper.local.properties` was the following:
```INI
compilers=vyper
compilerType=vyper
versionFlag=--version
compiler.vyper.exe=/opt/research/godbolt/venv/bin/vyper
compiler.vyper.isSemVer=true
compiler.vyper.instructionSet=evm
compiler.vyper.options=--optimize none
```
The versions tested are the latest major Vyper release 0.4.0, along with
0.3.10 and earlier 0.3.xx releases.
It appears that there is support for running python in a virtual
environment in the infra repository:
https://github.com/compiler-explorer/infra/blob/main/bin/lib/installable/python.py
However, I've had difficulties getting started with it and would greatly
appreciate any assistance. Thank you!
1. Gives a proper type to the metadata
2. Fixes a typo in `screenshot_dimentions`
3. Removes home-made partition function in favor of underscore
4. Reads file asynchronously (and consequently rest of API is async)
5. Strips the `https://godbolt.org/#` from each entry in the config file
As an added benefit this should also cut some startup time reading this
file before it's used :)
This patch adds two options to the clangir pane that affects the clangir
compilation pipeline:
* Flat CIR enables the emission of flat clangir CFG;
* -fclangir-mem2reg enables the mem2reg pass on the flat clangir CFG.
for https://github.com/compiler-explorer/compiler-explorer/issues/2331
Hey, so I am currently trying to improve the SPIR-V ecosystem, in-charge
of the [SPIR-V Guide](https://github.com/KhronosGroup/SPIRV-Guide), and
part of the SPIR-V Working Group. We talked at our last Face-2-Face
gathering about getting more support for GPU tooling in something like
Compiler Explorer because you have all made this such an amazing tool!
I have enjoyed working in this codebase and happy to help keep improving
the SPIR-V as people find issues or want enhancements (I was already
about to spend time rebuilding Compiler Explorer, so happy to donate my
time to a single tool's effort)
(For those who haven't spent last few years staring at SPIR-V)
- SPIR-V is a an IR (very much like LLVM IR) but for GPUs
- SPIR-V can be used for Graphics and Compute
- Compute:
- Can be tied to things like clang, llvm, mlir, OpenCL, etc
- One could take `spirv` as a language and compile it to something like
x86
- (Future PRs for this realm of things)
- Graphics:
- Much harder to actually "compile" to any ISA because other graphics
pipeline information is missing that will effect the final ISA
- Microsoft has even now planned to move to [SPIR-V for DirectX
soon](https://devblogs.microsoft.com/directx/directx-adopting-spir-v/)
- Both:
- There are many tools that run on SPIR-V regardless (hence why they
share the same IR)
- Being able to do tooling in compiler explorer would be AMAZING
This PR adds `SPIR-V` as a language and a new `SPIRV-Tools` compiler as
an initial compiler for it the language (since we already have the
SPIRV-Tools repo being pulled in on the infra side!)
I personally use `spirv-opt` and `spirv-val` the most and have been
testing this locally for a few days and feel it is ready to go. I plan
to slowly add more tools (ex. `spirv-fuzz`, `spirv-cross`,
`spirv-reflect`, etc)
Cheers!
(some screenshots of course)
