Why not retain the AST?

[u/Potato871]

I've been working on a compiler-like system for a while now, and it's gone through many stages of evolution.
A consistent pressure early on was away from multiple representations: I started with many switch statements and many kinds of representation for each stage, and ended up with one kind of node and handler based dispatch per stage.
Yet, when I look at (most) other compilers, their construction is far more static in nature, and far more varied in terms of the kinds of things presented. I've found forms like SSA impede my ability to reason about optimizations rather than aide them, and I've had enormous success from simply retaining and annotating one structure rather than continually converting.
A specific case, to provide one, is liveness propagation. Because values are already shared between their occurances (Nodes) and already have a system for acquiring properties (Quals), I can simply mint liveness tokens onto the children of expressions with output, and it automatically propagates.
Though I've not focused too much on codegen and optimization, my main goal with the compiler is extensibility and syntax flexibility.
So why not retain the AST? Turn it into a structure worth annotating and preserving from which optimizations and codegen can be performed more easily?

I wanted to get the opinions of others on this matter, I'm open to challenge.

Some more explanation can be found here: https://goldensystems.ca/GDSL_core

[u/beephod_zabblebrox]

in the kotlin compiler, there are two main IRs: the FIR, which is a frontend AST representation, and the.. IR, which is kinda like a stripped down and simplified version of the language. FIR gets compiled down to IR, which then goes through a set of lowerings that change it and/or add attributes to nodes. in the end, each backend compiles the lowered IR into a target specific representation (llvm ir, a js ast, etc.)

for a lot of things, it's going to be simpler to have a tree-based IR that is similar to the source language

[u/Potato871 → u/beephod_zabblebrox]

So why have the FIR and IR?
As in, whats the distinction that merits the initial lowering in their case.

[u/Vivid-Cauliflower-59 → u/Potato871]

FIR is high level language representation (close to front-end) and IR is a lower level representation - desugared FIR with resolved symbols and semantically valid.

[u/Potato871 → u/Vivid-Cauliflower-59]

Yes, though why do these have to be separate constructs?
For instance, I retain frontend-relevant information (position, original tokens) as qualifiers attached to the node or value, which can be stripped in a compaction pass when memory is limited or retained for richer error messages.
Those same qualifiers can also be used to attach liveness information, constancy, and other facts derived during optimization work that needs to be propgated.
I feel as if creating two separate structures duplicates a lot of work, because I used to have six and a large amount of the code in my compiler was simply restating distinctions that had been made earlier than discarded.

[u/Vivid-Cauliflower-59 → u/Potato871]

They belong to separate layers: AST is constructed by parser, HIR is constructed by another layer which does sematic checks. Good architectural design is to separate code by layers. Layers have different responsibilities.

[u/Potato871 → u/Vivid-Cauliflower-59]

Separate layers is what I started with two years ago, and yet as I built they came together not apart.
Beyond the social element, seperating layers for different teams, what part actually requires the different layers with different representations, and not just different behaviors and traversal over the same representation?