ICE with xtensa backend

[TurkeyMan]

I've been tinkering with the xtensa backend; showing excellent progress! Builds most code, but I'm seeing a weird crash in the backend when I enable any optimisations (essential to minimise code size) in conjunction with exception handling... I think this is reduced from my situation:

// ldc2 -mtriple=xtensa-none-elf -mattr=+density,+mul16,+mul32,+div32,+windowed -O1 -c

module xtensa_eh_crash;

void external_call(int delegate(const(char)[], int) dg);

int opApply(int delegate(const(char)[], int) dg)
{
    int result;
    try
    {
        external_call(dg);
    }
    catch (Exception e)
    {
        result = -1;
    }
    return result;
}

I'm using the LLVM21 build.
Can you imagine any reason this would cause a problem?

[TurkeyMan]

Incidentally, it doesn't seem that exceptions crash uniformly; I have some other try/catch blocks that don't ICE... so it seems situational.

EDIT: sorry, I think my test was bad; uninstantiated templates after reducing. I think exceptions are broken.

[thewilsonator]

was bag

? bad?

[TurkeyMan]

Yes, uninstantiated template fail. try/catch explodes when I enable any level of optimisation.

[kassane]

Currently, only LLVM upstream has this error, because it does not have EH register overrides in XtensaISelLowering.
ref.: https://github.com/espressif/llvm-project/blob/b2a113839eaf86ba4d54937ddd225cbba5d5e4a7/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L411-L423

[TurkeyMan]

How much trouble would it be to use espressif's patches? Is there a patch stack applied to LDC builds, or is it all neat?

[kinke]

I'd definitely prefer things to stay as-is, no 3rd-party mods to LLVM. Our LLVM fork has around 8 commits or so on top of the upstream release branch, for a few mods of ours, plus setting up the CI machinery for package generation + upload. LLVM 22 support is coming soon.

[TurkeyMan]

Xtensa still haven't finished their own upstream process. It's been moving very slowly for years.

[kassane]

How much trouble would it be to use espressif's patches? Is there a patch stack applied to LDC builds, or is it all neat?

Using these differences simply means replacing LLVM. ldc2 does not require any specific changes.

In theory, this shouldn't be a problem, especially since ldc2 doesn't add CPU features by default in cross-compilations of targets. (missing tablegen support in bootstrap)

[TurkeyMan]

"replacing LLVM" doesn't sound cool. it's suuuper nice that I can build all my targets with one LDC binary; it simplifies CI, devops, build machine config, etc to an unbelievable degree. It improves build times so much.