Your compiler targets every machine.
We target yours.
Evo builds the compiler for your software and your hardware, end to end: optimizations discovered for your code, proven correct, measured on your machine, and delivered as a deterministic toolchain you build with.
GPU
- compute
- SIMT, warp-synchronous
- memory
- register → shared → HBM
- operations
- MMA, async copy, shuffle
Edge accelerator
- compute
- 8-wide SIMD MAC
- memory
- 64 KB scratchpad, DMA in
- operations
- int8 dot, saturating add
Custom silicon
- compute
- 16×16 systolic MAC array
- memory
- on-chip weight residency
- operations
- fixed-point MAC, no divide
A compiler that keeps what it learns.
Hand-tuning ends when the engagement does. Evo is built so a win found once becomes something the compiler can apply again: a pass, with the conditions it depends on written down.
read the full Evo thesis- 01
Discover
Evo reads the hot code, the description of your target and the constraints around both, then searches for transforms: layouts, tilings, schedules, fusions, instruction choices, algorithm substitutions.
inputhot code + target descriptionoutputcandidate transformationsstatusspeculative by construction - 02
Prove
A candidate arrives with the preconditions it assumes and the equivalence it claims. Those obligations are checked mechanically, at the scope the transformation actually applies to. Anything that cannot be discharged is dropped — the search never gets to assert that its own transform is correct.
checkspreconditions, equivalence obligationsscopethe region the transform applies toon failurediscarded, with the reason kept - 03
Measure
Survivors are benchmarked in the target environment, repeated until the distribution is stable, and held against a regression gate. A transformation that is correct but not faster on the machine in front of it is not admitted.
environmentthe target you deploy onreporteddistribution, not a single rungateregression rejects the candidate - 04
Admit
An admitted transformation stops being a suggestion. It enters the library as a pass with its preconditions attached, applied by the compiler when those preconditions hold. Nothing probabilistic sits in your build path.
formpass + preconditionsappliedwhen preconditions holdbuild pathdeterministic, model-free - 05
Reuse
The library is the point. Optimizations discovered for one program and machine are available to the next program that satisfies the same preconditions, which is what makes the search worth paying for more than once.
unitreusable pass, not a patchconditionpreconditions must hold againeffectsearch cost amortizes
note — what can be checked, and how completely, depends on the transformation and the region it applies to. Evo's position is narrower than “all programs are proven equivalent”: a candidate states the preconditions it assumes and the equivalence it claims, those obligations are discharged mechanically, and anything left open is rejected rather than shipped.
Seven layers decide how fast your program is.
A speedup can come from any of them, and the interesting ones come from the interaction between two. Evo works the whole span rather than optimizing one layer against assumptions about the next.
Transformation and scheduling
Where the specialization happens: tiling, fusion, layout, instruction selection, scheduling — against one machine rather than a class of machines.
- Custom passes and lowering
- Discovered transformation library
- Proof-gated promotion
hover or focus a layer — “core” marks where the compiler and the hardware contract meet, which is the part we think is under-worked
Search can be probabilistic.
Compilation cannot.
Search is a good source of ideas and a bad source of authority. Evo keeps those roles apart inside the product: its search, models included, sits outside the boundary and proposes; a deterministic checker and a clock on your target decide what crosses it.
✕ trip count not established · fault path differs · reassociation outside declared tolerance · accumulator overflow open
representative candidates — rejection is the common case, and the reason is kept
- search
Propose, never decide
A candidate is an input to the pipeline, not a conclusion. Confidence is not evidence.
- checker
Deterministic and repeatable
The same candidate produces the same verdict. Nothing is promoted because a review looked fine.
- clock
Measured on the target
Correct but not faster on the machine in front of it is still a rejection.
- output
A pass, not a suggestion
What crosses the boundary is compiler capability with its preconditions attached. Nothing probabilistic in your build path.
The boundary is where the performance goes.
Evo treats the program, the machine, and the compiler layer between them as one system. The distance between what a program means and what a machine actually does is one of the largest and least examined sources of waste in computing.
- 01
Generality is expensive
A general-purpose compiler has to be right for every program on every supported target, so it is rarely great for yours. What it leaves behind is large, repeatable and mostly invisible.
- 02
Hand-won speed never reaches the compiler
When a team closes the gap by hand, the result lives in one codebase and leaves with the engagement. Nothing carries it back into the toolchain that built it.
- 03
Search changed the economics
Proposing candidate transformations is now cheap. What was missing is infrastructure willing to reject almost all of them and keep the rest.
- based in
- San Francisco, CA
- delivery
- end to end
- span
- workload → silicon
- output
- deterministic artifact
Ready for your next leap in performance?
Three things tell us whether Evo fits: what you compile, the machine it runs on, and the constraint you are actually up against. A paragraph is enough to start.
- team@velobyte.ai
- based in
- San Francisco, CA
- good first step
- one kernel, one machine, one number that matters