alex-s168's blog

Paying for things

alexander.nutz@vxcc.dev (Alexander Nutz)

Paying for things

Last modified: 12. April 2026 20:07 (Git #f6a9bb61)

These days, most things are available for “free”. Google search is free. G-Mail is free. Even Google Photos is free?? Obviously things are not free because the companies are nice. The companies want to collect your data, and show you ads.

The situation’s gotten so bad, that most people refuse to pay for small things [citation needed].

There is a good article by Kagi (search engine & more), about why you should pay for search.

You should pay for everything you use. Especially things you use many times daily, like search engines, your e-mail software, your web browser, and even your desktop compositor!

Many people will say “But what about free and open source!”. No. YOU should pay for everything you use. Of course you should not have to pay a subscription, and the software should not have a paywall (or at least not a restrictive paywall), but you, as user, should be willing to pay the software maintainers, developers, and hosters!

Of course this does not apply to shitty or LLM-written software, like Windows, or GitHub. Quality software deserves your hard‑earned cash . This also applies to other media like: music, entertainment, educational content, photographs, blog articles, …

NO Pay-walls!

Just because I said you should pay for media, like blog articles, doesn’t mean everyone should start putting paywalls infront of their blogs! Quite the opposite actually! All research, summaries of research, etc, should be publicly accessible (for free)!

Instead, blogs could have a (non-intrusive!) donate button. Normalize micro-transactions on the web! (These could be implemented with for example Cardano, or more privacy focused DeFi)

Against streaming subscriptions

Even though streaming subscriptions are nice in theory, media should not be streamed. You should be able to own your media.

Potential alternatives, with music as example:

Buy the album/song once, and get the raw audio file. Bandcamp allows you to do that.
Always have access to the raw audio file, but reliably pay the creators depending on how often you listen to it.

The only thing worse than streaming music, is DRM:

Against subscriptions in general

There are two kinds of subscription users:

underuses their subscription: they pay much more for the subscription, than they would have paid for each item / stream / search / …
overuses their subscription: they save a ton of money by having the subscription, and pay less per item than most others.

The second kind is rather uncommon, so most companies that offer subscriptions do so, knowing that users will underuse them, and they can make more money that way.

Probably another reason subscription exists, is that it’s hard to do seamless micro-transactions. When you do an DeFi payment, typically only your wallet pops up immediately, and you can click pay, and it just works. When you do for example a PayPal payment, you often have to log-in again, the payment website loads really slowly, etc. This could easily be fixed by the payment processors, if they actually cared. But obviously they don’t.

What can you do?

Consider paying or donating to the software you use daily. For example use Kagi search , donate to your linux desktop environemnt developers, buy songs as directly from artists as possible, …

Truthear HEXA vs PURE vs GATE

alexander.nutz@vxcc.dev (Alexander Nutz)

HEXA vs PURE vs GATE Review

Truthear HEXA vs PURE vs GATE

Last modified: 12. April 2026 20:07 (Git #f6a9bb61)

Written by Alexander Nutz

After being sick of bad headphones, I decided to buy Truthear HEXAs for 99€, and they were by far the best headphones I ever tried…

They produce a really clear sound, with strong bass, allowing you to notice musical details you would have never heard with most cheap setups. However! sometimes you don’t catch the “vibe” of the music; they force you to overanalyze everything, they are almost too optimal; Quoting the HEXA product page: “Present the excellent objective index” .

That didn’t annoy me too much tho, so I just decided to keep them. But one day, when pulling the headphones out of my bag, I was shocked to see that I snapped the left headphone-connecting pins on the cable in half! Turns out you’re not supposed to just throw them into a bag…

I managed to “repair” the cable by soldering on different pins, but the wires aren’t just standard multi-strand copper wires, so I had a hard time soldering on new contacts, and the fix broke after a few days.

Since cheap & good replacement cables are hard to find, I decided to buy Truthear GATEs for 20€, which have compatible cables. But I was thinking: “might as well get another pair of headphones as comparision”, so I decided to also get Truthear PUREs for 99€…

Comparision

GATE: 20 € (at time of writing)
HEXA: 99 € (at time of writing)
PURE: 99 € (at time of writing)

GATE

Really solid for the price point. They have a similar “clearness” to the HEXAs, but are noticably worse than both HEXAs and PUREs

HEXA vs PURE

It’s easy to notice that they sound different, but it’s hard to tell which is “better”…

The PUREs sound more “fun” and warm than the HEXAs

Recommendation based on genre:

Dark R&B: I think the clear sound of the HEXAs is much better for lots of Dark R&B
HipHop: PUREs sound more exciting, and seem to have better bass
EDM: The PUREs have better bass in many songs, but tend to be noticably worse than the HEXAs for lead & vocals

Also consider that according to Truthear, the PUREs are supposed to be an improvement over the HEXA design, based on feedback by “professionals”…

Favourites

If I could only pick one, I’d go with the HEXAs; Even though the “clearness” is annoying sometimes, they just sound much better than “warm”er headphones, like the PUREs or the ZERO:RED (which I tried for one day when getting the HEXAs, and then returned), in most cases.

Keep in mind that I’m not a “professional”, so you should definitely read other people’s reviews too. If you don’t want to spend 100€ on headphones, you should probably get GATEs; they are good enough for most things.

Foam Eartips

In my opinion, the foam eartips sound much better than the silicone eartips; Sadly the GATEs don’t come with any, and the HEXAs and PUREs only with one set. Be careful with the included foam eartips! They break easily…

If you need replacement eartips, I suggest getting Comply eartips. You can just click the button on the top right, and enter the model name of your headphones.

I got Comply 600 core series (small & medium) eartips, which work for the HEXAs, GATEs, and PUREs. They seem to last much longer than the included eartips, and also don’t itch after wearing for a long time.

Also note that getting slightly larger eartips means better sound (and less sound from the environment), but might hurt a bit after wearing them for long.

Challenges with automatically inlining functions

alexander.nutz@vxcc.dev (Alexander Nutz)

Challenges with automatically inlining functions

Last modified: 12. April 2026 20:07 (Git #f6a9bb61)

Written by Alexander Nutz

Introduction

Function calls have some overhead, which can sometimes be a big issue for other optimizations. Because of that, compiler backends (should) inline function calls. There are however many issues with just greedily inlining calls…

Greedy inlining with heuristics

This is the most obvious approach. We can just inline all functions with only one call, and then inline calls where the inlined function does not have many instructions.

Example:

function f32 $square(f32 %x) {
@entry:
  // this is stupid, but I couldn't come up with a better example
  f32 %e = add %x, 0
  f32 %out = mul %e, %x
  ret %out
}

function f32 $hypot(f32 %a, f32 %b) {
@entry:
  f32 %as = call $square(%a)
  f32 %bs = call $square(%b)
  f32 %sum = add %as, %bs
  f32 %o = sqrt %sum
  ret %o
}

function f32 $tri_hypot({f32, f32} %x) {
  f32 %a = extract %x, 0
  f32 %b = extract %x, 1
  f32 %o = call $hypot(%a, %b) // this is a "tail call"
  ret %o
}

// let's assume that $hypot is used someplace else in the code too

Let’s assume our inlining treshold is 5 operations. Then we would get – Waait there are multiple options…

Issue 1: (sometimes) multiple options

If we inline the $square calls, then $hypot will have too many instructions to be inlined into $tri_hypot:

...
function f32 $hypot(f32 %a, f32 %b) {
@entry:
  // more instructions than our inlining treshold:
  f32 %ase = add %a, 0
  f32 %as = mul %ase, %a
  f32 %bse = add %b, 0
  f32 %bs = mul %bse, %b
  f32 %sum = add %as, %bs
  f32 %o = sqrt %sum
  ret %o
}
...

The second option is to inline the $hypot call into $tri_hypot. (There are also some other options)

Now in this case, it seems obvious to prefer inlining $square into $hypot.

Issue 2: ABI requirements on argument passing

If we assume the target ABI only has one f32 register for passing arguments, then we would have to generate additional instructions for passing the second argument of $hypot, and then it might actually be more efficient to inline $hypot instead of $square.

This example is not realistic, but this issue actually occurs when compiling lots of code.

Another related issue is that having more arguments arranged in a fixed way will require lots of moving data arround at the call site.

A solution to this is to make the heuristics not just output code size, but also make it depend on the number of arguments / outputs passed to the function.

Issue 3: (sometimes) prevents optimizations

function f32 $myfunc(f32 %a, f32 %b) {
@entry:
  f32 %sum = add %a, %b
  f32 %sq = sqrt %sum
  ...
}

function $callsite(f32 %a, f32 %b) {
@entry:
  f32 %as = mul %a, %a
  f32 %bs = mul %b, %b
  f32 %x = call $myfunc(%as, %bs)
  ...
}

If the target has a efficient hypot operation, then that operation will only be used if we inline $myfunc into $callsite.

This means that inlining is now depended on… instruction selection??

This is not the only optimization prevented by not inlining the call. If $callsite were to be called in a loop, then not inlining would prevent vectorization.

Function outlining

A related optimization is “outlining”. It’s the opposite to inlining. It moves duplicate code into a function, to reduce code size, and sometimes increase performance (because of instruction caching)

If we do inlining seperately from outlining, we often get unoptimal code.

A better approach

We can instead first inline all inlinable calls, and then perform more agressive outlining.

Step 1: inlining

We inline all function calls, except for:

self recursion (obviously)
functions explicitly marked as no-inline by the user

Step 2: detect duplicate code

There are many algorithms for doing this.

The goal of this step is to both:

maximize size of outlinable section
minimize size of code

Step 3: slightly reduce size of outlinable section

The goal is to reduce size of outlinable sections, to make the code more optimal.

This should be ABI and instruction depended, and have the goal of:

reducing argument shuffles required at all call sites
reducing register preassure
not preventing good isel choices and optimizations.

this is also dependent on the targetted code size.

Step 4: perform outlining

This is obvious.

Issue 1: high compile-time memory usage

Inlining all function calls first will increase the memory usage during compilation by A LOT

I’m sure that there is a smarter way to implement this method, without actually performing the inlining…

Conclusion

Function inlining is much more complex than one might think.

Subscribe to the Atom feed to get notified about futre compiler-related articles.

Approaches to pattern matching in compilers

alexander.nutz@vxcc.dev (Alexander Nutz)

Approaches to Compiler Pattern Matching

Approaches to pattern matching in compilers

Last modified: 12. April 2026 20:07 (Git #f6a9bb61)

Written by Alexander Nutz

Introduction

Compilers often have to deal with pattern matching and rewriting (find-and-replace) inside the compiler IR (intermediate representation).

Common use cases for pattern matching in compilers:

“peephole optimizations”: the most common kind of optimization in compilers. They find a short sequence of code and replace it with some other code. For example replacing x & (1 << b) with a bit test operation.
finding a sequence of operations for complex optimization passes to operate on: advanced compilers have complex optimizations that can’t really be performed with simple IR operation replacements, and instead require complex logic. Patterns are used here to find operation sequences where those optimizations are applicable, and also to extract details inside that sequence.
code generation: converting the IR to machine code / VM bytecode. A compiler needs to find operations (or sequences of operations) inside the IR, and “replace” them with machine code.

Simplest Approach

Currently, most compilers mostly do this inside their source code. For example, in MLIR, most (but not all) pattern matches are performed in C++ code.

The only advantage to this approach is that it doesn’t require a complex pattern matching system.

I only recommend doing this for small compiler toy projects.

Disadvantages

Doing pattern matching this way has many disadvantages.

Some (but not all):

debugging pattern match rules can be hard
IR rewrites need to be tracked manually (for debugging)
source locations and debug information also need to be tracked manually, which often isn’t implemented very well.
verbose and barely readable pattern matching code
overall error-prone

I myself did pattern matching this way in my old compiler backend, and I speak from experience when I say that this approach sucks (in most cases).

Pattern Matching DSLs

A custom language for describing IR patterns and IR transformations (aka rewrites).

I will put this into the category of “structured pattern matching”.

An example is Cranelift’s ISLE DSL:

;; x ^ x == 0.
(rule (simplify (bxor (ty_int ty) x x))
      (subsume (iconst_u ty 0)))

Another example is tinygrad’s pattern system:

(UPat(Ops.AND, src=(
   UPat.var("x"),
   UPat(Ops.SHL, src=(
     UPat.const(1),
     UPat.var("b")))),
 lambda x,b: UOp(Ops.BIT_TEST, src=(x, b)))

Fun fact: tinygrad actually decompiles the python code inside the second element of the pair, and runs multiple optimization passes on that.

This approach is used by many popular compilers such as LLVM, GCC, and Cranelift for peephole optimizations and code generation.

Advantages

debugging and tracking of rewrites, source locations, and debug information can be done properly
patterns themselves can be inspected and modified programmatically.
they are easier to use and read than manual pattern matching in the source code.

There is however an even better alternative:

Pattern Matching Dialects

I will also put this method into the category of “structured pattern matching”.

The main example of this is MLIR, with the pdl and the transform dialects. Sadly few projects/people use these dialects, and instead do pattern matching in C++ code. Probably because the dialects aren’t documented very well.

What are compiler dialects?

Modern compilers, especially multi-level compilers, such as MLIR, have their operations grouped in “dialects”.

Each dialect either represents specific kinds of operations, like arithmetic operations, or a specific backend’s/frontend’s operations, such as the llvm, emitc, and the spirv dialects in MLIR.

Dialects commonly contain operations, data types, as well as optimization and dialect conversion passes.

Core Concept

The IR patterns and transformations are represented using the compiler’s IR. This is mostly done in a separate dialect, with dedicated operations for operating on IR.

Examples

MLIR’s pdl dialect can be used to replace arith.addi with my.add like this:

pdl.pattern @replace_addi_with_my_add : benefit(1) {
  %arg0 = pdl.operand
  %arg1 = pdl.operand
  %op = pdl.operation "arith.addi"(%arg0, %arg1)

  pdl.rewrite %op {
    %new_op = pdl.operation "my.add"(%arg0, %arg1) -> (%op)
    pdl.replace %op with %new_op
  }
}

Advantages

the pattern matching infrastructure can optimize it’s own patterns: The compiler can operate on patterns and rewrite rules like they are normal operations. This removes the need for special infrastructure regarding pattern matching DSLs.
the compiler could AOT compile patterns
the compiler could optimize, analyze, and combine patterns to reduce compile time.
IR (de-)serialization infrastructure in the compiler can also be used to exchange peephole optimizations.
bragging rights: your compiler represents its patterns in it’s own IR

Combining with a DSL

I recommend having a pattern matching / rewrite DSL, that transpiles to pattern matching / rewrite dialect operations.

The advantage of this over just having a rewrite dialect is that it makes patterns even more readable (and maintainable!)

E-Graphs

E-Graphs are magical datastructures that can be used to efficiently encode all possible transformations, and then select the best transformation.

An example implementation is egg

Even though E-Graphs solve most problems, I still recommend using a pattern matching dialect, especially in multi-level compilers, to be more flexible, and have more future-proof pattern matching, or you decide that you want to match some complex patterns manually.

More Advantages of Structured Pattern Matching

Smart Pattern Matchers

Instead of brute-forcing all peephole optimizations (of which there can be a LOT in advanced compilers), the compiler can organize all the patterns to provide more efficient matching. I didn’t yet investigate how to do this. If you have any ideas regarding this, please contact me.

There are other ways to speed up the pattern matching and rewrite process using this too.

Reversible Transformations

I don’t think that there currently is any compiler that does this. If you do know one, again, please contact me.

Optimizing compilers typically deal with code (mostly written by people) that is on a lower level than the compiler theoretically supports. For example, humans tend to write code like this for extracting a bit: x & (1 << b), but compilers tend to have a high-level bit test operation (with exceptions). A reason for having higher-level primitives is that it allows the compiler to do more high-level optimizations, but also some target architectures have a bit test operation, that is more optimal.

This is not just the case for “low-level” things like bit tests, but also high level concepts, like a reduction over an array, or even the implementation of a whole algorithm. For example LLVM, since recently, can detect implementations of CRC.

LLVM actually doesn’t have many dedicated operations like a bit-test operation, and instead canonicalizes all bit-test patterns to x & (1 << b) != 0, and matches for that in compiler passes that expect bit test operations.

Now let’s go back to the x & (1 << b) (bit test) example. Optimizing compilers should be able to detect that, and other bit test patterns (like x & (1 << b) > 0), and then replace those with a bit-test operation. But they also have to be able to convert bit-test operations back to their implementation for compilation targets that don’t have a bit-test instruction. Currently, compiler backends do this by having separate patterns for converting bit-test to it’s dedicated operation, and back.

A better solution is to associate a set of implementations with the bit test operation, and make the compiler automatically reverse those to generate the best implementation (in the instruction selector for example).

Implementing pattern/transformation reversion can be challenging however, but it provides many benefits, and all “big” compilers should definitely do this, in my opinion.

Runtime Library

Compilers typically come with a runtime library that implement more complex operations that aren’t supported by most processors or architectures.

The implementation of those functions should also use that pattern matching dialect. This allows your backend to detect code written by users with a similar implementation as in the runtime library, giving you some additional optimizations for free.

I don’t think any compiler currently does this either.

Problems with Pattern Matching

The main problem is ordering the patterns.

As an example, consider these three patterns:

;; A
(add x:Const y) => (add y x)

;; B
(sub (add x y:Const) z:Const) => (lea x y (const_neg z))

;; C
(add x 1) => (inc x)

Now what should the compiler do when it sees this:

(sub (add 5 1) 2)

All three patterns would match:

;; apply A
(sub (add 5 1) 2) => (sub (add 1 5) 2)
;; only B applies now
(sub (add 1 5) 2) => (lea 1 5 (const_neg 2))
;; nothing applies anymore

;; alternatively apply B
(sub (add 5 1) 2) => (lea 5 1 (const_neg 2))
;; nothing applies anymore

;; atlernatively apply C
(sub (add 5 1) 2) => (sub (inc 5) 2)
;; nothing applies anymore

Now which of those transformations should be performed?

This is not as easy to solve as it seems, especially in the context of instruction selection (specifically scheduling), where the performance on processors depends on a sequence of instructions, instead of just a single instruction.

Superscalar CPUs

Modern processor architecture features like superscalar execution make this even more complicated.

As a simple, unrealistic example, let’s imagine a CPU (core) that has one bit operations execution unit, and two ALU execution units / ports.
This means that the CPU can execute two instructions in the ALU unit and one instruction in the bit ops unit at the same time.

One might think that always optimizing a & (1 << b) to a bit test operation is good for performance. But in this example, that is not the case.

If we have a function that does a lot of bitwise operations next to each other, and the compiler replaces all bit tests with bit test operations, suddenly all operations depend on the bit ops unit, which means that instead of executing 3 instructions at a time (ignoring pipelining), the CPU can only execute one instruction at a time.

This shows that we won’t know if an optimization is actually good, until we are at a late point in the compilation process where we can simulate the CPU’s instruction scheduling.

This does not only apply to instruction selection, but also to more higher-level optimizations, such as loop and control flow related optimizations.

Conclusion

One can see how pattern matching dialects are the best option to approach pattern matching.

Someone wanted me to insert a takeaway here, but I won’t.

PS: I’ll hunt down everyone who still decides to do pattern matching in their compiler source after reading this article.

Making the favicon

alexander.nutz@vxcc.dev (Alexander Nutz)

It turns out that websites need a favicon, and making one is hard...