On Wed, Mar 19, 2025 at 7:02 PM Quentin Carbonneaux <quentin@c9x.me> wrote:
>
> On Sat, Nov 16, 2024, at 09:53, Roland Paterson-Jones wrote:
> > Replacement of tiny conditional jump graphlets with
> > conditional move instructions.
>
> I think I made this work on top of master in the dev branch
> of git://c9x.me/qbe.git. On my machine, the coremark gains
> are impressive (11700 -> 14600; 15400 is 70% of gcc -O2.).

LGTM :)

On my AMD Ryzen 5 6600H coremark is 20600 -> 24100.

On Fri, Feb 14, 2025 at 1:16 PM Quentin Carbonneaux <quentin@c9x.me> wrote:

> > Now filluse() does not appear to have any handling for RMem refs; but
> > it is called after the isel phase.

> But it's never called after isel, is it?

Doh, indeed. It's only in one of my dev branches that I'm calling
filluse() after isel().

Mea culpa.

On Tue, Feb 11, 2025 at 2:15 PM Michael Forney <mforney@mforney.org> wrote:

> Here's a minimized reproducer:
>
>         export function $f() {
>         @start
>                 %t1 =l alloc4 4
>         @cond
>                 %t2 =w loadw %t1
>                 %t3 =w ceqw %t2, 0
>                 jnz %t3, @loop, @done
>         @loop
>                 storew 1, %t1
>                 jmp @cond

Welcome back Michael :)

On Tue, Feb 11, 2025 at 2:15 PM Michael Forney <mforney@mforney.org> wrote:
>
> I don't think we can error here. While the reproducer and the
> original program did have uninitialized reads, it's possible to
> construct a program which doesn't and still triggers the assertion.

I remember discussing similar stuff a while back, but all I could find was

https://lists.sr.ht/~mpu/qbe/%3C25ULB5G9O7MEM.282ETTWXDHRX7@mforney.org%3E

R

As far as I can see the check that npm < Tmp0 is just bogus
because the "parallel move" list can include an indefinite
number of moves to/from (stack) slots.

Accordingly, change the pm list to a vector and allow
indefinite growth.

Passes QBE unit tests, cproc bootstrap, harec/hare.

No longer dies on
https://paste.sr.ht/~turminal/88d767b6ad3f8a3c57a6523467ca209e3cbb83c0

Whether pmrec() does the right thing for stack slots is
another question entirely, but presumably so because it is
[message trimmed]

Hey Scott

On Fri, Feb 7, 2025 at 8:13 PM Scott Graham <sgraham@gmail.com> wrote:
>
> Thanks for looking!

You're welcome? I'm not sure what the correct vernacular is. Pretty
impressive work regardless.

> On Fri, Feb 7, 2025 at 6:19 AM Roland Paterson-Jones <rolandpj@gmail.com> wrote:
>
> > non-contiguous caller/callee-save register layout
>
> Hmm, yeah, ... Do you have any suggestions of

Hey Scott, kudos for biting the bullet :)

I took a very brief look. The only thing that made me immediately
nervous was the non-contiguous caller/callee-save register layout due
to rsi/rdi. Unfortunately rega.c in QBE is not my forte, but I recall
that the QBE register lay-out seemed deliberate.

Support for Windows LLP64 (long vs int64_t, PRIu64 etc.) is
awkward/irritating but perhaps a necessary abstraction. I guess a
proper audit is needed to ensure that, for example, cross-compilation
between sysv/win works OK(tm). Similarly, dup'ing getopt() support is
irritating.

Then of course as you mentioned, the // and long_named_symbols

Here's a curiosity I stumbled on.

The (x86) T.isel() phase creates RMem references, which are
essentially compound addresses [base + N*index].

Now filluse() does not appear to have any handling for RMem refs; but
it is called after the isel phase.

Accordingly, tmp uses as part of compound RMem instruction arguments
are not reflected in the resulting uses.

This seems dubious at best?
R

On Sun, Jan 26, 2025 at 1:07 AM Quentin Carbonneaux <quentin@c9x.me> wrote:
>
> On Sat, Jan 25, 2025, at 20:00, Maroš Grego wrote:
> > In light of the discussion here, would there be an interest in patches
> > making QBE
> > use less global static variables, thus making it more amenable to use
> > as a library?
>
> Sigh, I'll miss the readability. Maybe using
> context objects?

Lol, your baby is out there now and everyone wants to play with it :P

Yes, as Scott mentioned before, context encapsulation is really what

Hey Roberto

On Sun, Jan 26, 2025 at 4:55 PM Roberto E. Vargas Caballero
<k0ga@shike2.com> wrote:

> You don't need QBE moving the observable load/stores.
> The CPU is already doing that based in the memory model
> implemented by the processor. ARM CPUs are very bad about
> this topic

Indeed, I have scars from debugging very subtle "weak coherency"
problems on processors like IBM's POWER series.

x86's coherency protocols - MESI etc - tend to mask a lot of this.