I really want to like QBE, but declaration blocks like this make it feel like 1970s Unix code more than a modern hackable piece of software:

    int t, x, r, rf, rt, nr;
    bits rs;
    Ins *i, *i1;
    Mem *m;
    Ref *ra[4];

I think it deters some users by making it hard to read and understand the relatively subtle code in the 300 line function that follows. (Skill issue, I know)

▲ orthoxerox 3 hours ago | parent | next [-]

Yeah, I tried my hand at adding amd64_win support to QBE, but going through the very dense code was a slog. I kept refactoring and commenting it just to make heads or tails of it, but ultimately realized I would never be able to minify it back to something upstreamable. I applaud Scott Graham's perseverance and tenacity.

	▲	s3graham an hour ago \| parent [-]
		Quentin took pity on me and let me upstream amd64_win with my lengthy variable names and including chatty comments. :) SysV and Win x64 differ enough that the Windows code is mostly unrelated to/detached from the other backends, so it doesn't feel (too) awful for it to have its own idiosyncratic style.

▲ peterfirefly 3 hours ago | parent | prev | next [-]

I tried to look at the QBE code years ago while I was writing my own SSA code. I got approximately nowhere because I can't read code like that. Turns out that reading the SSA papers and writing the code was a lot easier than reading QBE.

▲ norir 5 hours ago | parent | prev | next [-]

It is hard for me to fully trust a compiler backend that isn't self hosted. There is a discipline that self hosting imposes that would both improve the quality of their ir as well as the backend itself. A self hosted backend can always be updated to have performance meeting or exceeding the best that llvm or any other backend can offer.

▲ IshKebab 4 hours ago | parent | prev [-]

Yeah that looks like they've prioritised code golfing a bit too much over code quality. Also using AT&T assembly syntax shows poor taste. Definitely 80s themed software.