This won't even compile. See amd64/isel.c:444

Quoth Feliks Weber <jummit@web.de>:
> ---
>  amd64/isel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/amd64/isel.c b/amd64/isel.c
> index bd645ce..1a41dd8 100644
> --- a/amd64/isel.c
> +++ b/amd64/isel.c
> @@ -403,7 +403,7 @@ sel(Ins i, Num *tn, Fn *fn)
>  		}
>  		seladdr(&i.arg[1], tn, fn);

Quoth Rosie <acquitefx@gmail.com>:
> Yeah, I suppose. From what I read, in LLVM when you do `alloca` you 
> explicitly request a stack slot, so surely allocN in QBE should act the 
> same way?
> 

yeah, though llvm also optimizes out unused stack slots. I think
that my contention is that letting the address of a stack slot
escape should count as a use.

Quoth Rosie <acquitefx@gmail.com>:
>  > But it is used: it gets returned.
> 
> It is? but don't both functions use `mov w0, #0` ie returning 0?
> 

my point is that this is (arguably) qbe doing not quite
the right thing.

Quoth Rosie <acquitefx@gmail.com>:
> I think this behavior is actually QBE just optimizing out unused stack 
> allocations completely, staring at it for a while. I do wish there was a 
> way to prevent this.
> 

But it is used: it gets returned. Technically, this is UB in C, but
I wonder if that's what we want in QBE IR.

Quoth Rosie <acquitefx@gmail.com>:
> I seem to have found the issue -- QBE seems to optimize variables deemed 
> small enough into general purpose registers instead of pushing them to 
> the stack

even if you take their address? that seems odd.

Quoth Rosie <acquitefx@gmail.com>:
> Update: I wrote a somewhat automatic runtime thing which automatically 
> compiles and links a tiny amount of assembly for the architecture that 
> the compiler was compiled on (only aarch64 and x86_64 are supported for now)
> 
> ```s
> .text
> .balign 4
> .global ___internal_get_frame_address
> ___internal_get_frame_address:
>      mov x0, x29
>      ret
> ```
> 

Quoth Atirut Wattanamongkol <atirut.wattanamongkol@gmail.com>:
> > Absolutely not
> 
> Hm? Why not, if you don't mind? I've been using CMake in all of my
> C/C++ projects for the editor integrations, so I'm curious.
> 

The last time I tried to do something non-trivial with cmake
I found myself debugging cmake with gdb to figure out what
script was screwing up the environment.

it's giant and undebuggable. It's incredible to me that the
C++ world didn't look at it and ask "are you pranking me?"

Quoth Quentin Carbonneaux <quentin@c9x.me>:
> On Wed, Dec 25, 2024, at 03:36, Alex // nytpu wrote:
> > I guess I should say up front, an ARM32 backend materializing from me is 
> > looking less and less likely by the day lol.  I'd poked at the QBE code 
> > before so I thought I could muddle through since I had the gist of what 
> > most of the code does, but it turns out it is extremely difficult to 
> > figure out how the code all fits together and *specifically* what many 
> > functions do.  And I can't easily just cargo cult from an existing 
> > backend since 32-bit requires a number of fundamental changes. Still 
> > persevering for the moment though.
> 
> I am currently spending all my qbe time integrating optimizations
> by Roland. When that is done, I'd be keen on providing a simple
> PoC with holes for you to plug.

There aren't any; you'll have to read the code and see how it's
done for other backends.

Quoth Atirut Wattanamongkol <atirut.wattanamongkol@gmail.com>:
> Hi all,
> 
> I’ve been working on a C compiler that targets the Z80 and integrates
> with the Binutils toolchain (mostly because there aren’t any Z80 C
> compilers that do this). My compiler uses LLVM IR internally since it
> seemed like a good choice at first, but I’ve run into some issues with
> register allocation and translating the IR to assembly (basically, the
> backend stuff).
> 
> I found out about this backend through a tutorial on writing a C

Quoth John Nunley <dev@notgull.net>:
> > I don't believe C needs it for anything.
> 
> C needs it for the top-level "asm" macro, right?
> 
> I guess you can push it into a ".S" file and compile that into the
> executable, but that seems kind of hacky.

C doesn't have a top level asm macro; there are some
compilers that have extensions for it, but not all
implementations have it, and the implementations are
not all compatible. They also have different levels
of integration with the register allocator.