This is an archive of the discontinued LLVM Phabricator instance.

[LoongArch] Use empty debug location for register spill/reload
ClosedPublic

Authored by benshi001 on Apr 13 2023, 10:53 PM.

Details

Summary

Spill/reload instructions are automatically generated by the compiler
and have no relation to the original source code. So it would be better
to not attach any debug location to them. The X86/AArch64/ARM/Thumb
backends all follow this way.

Diff Detail

Event Timeline

benshi001 created this revision.Apr 13 2023, 10:53 PM
benshi001 requested review of this revision.Apr 13 2023, 10:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 13 2023, 10:53 PM

Please check X86/ARM 's loadRegFromStackSlot and storeRegToStackSlot, they all use empty DebugLoc() instead of MachineBasicBlock::iterator::getDebugLoc().

I think this revision is not NFC, it does change the behavior of debug information.

benshi001 retitled this revision from [LoongArch][NFC] Use empty debug location for register spill/reload to [LoongArch] Use empty debug location for register spill/reload.Apr 13 2023, 11:54 PM

Looks good at first glance but would it be better to have some test coverage (if feasible)?

Looks good at first glance but would it be better to have some test coverage (if feasible)?

It is not easy to compose a proper test case for that, for example,

int foo;
int as(int a) {
        foo += a;
        return foo;
}

Build it with clang a.c -O0 -g --target=loongarch32, the difference is as following

We can see a .loc is eliminated by my patch. It is not good to test my patch with CHECK-NOT: .loc ***. We have to commit the test in another patch and then we can see the difference. But is it worthy to do so? This is just a tiny change.

xen0n accepted this revision.Apr 14 2023, 9:58 PM

We can see a .loc is eliminated by my patch. It is not good to test my patch with CHECK-NOT: .loc ***. We have to commit the test in another patch and then we can see the difference. But is it worthy to do so? This is just a tiny change.

Fine with me then, it's not one of those non-trivial changes that would benefit very much from test coverage anyway. I said "if feasible" in my original comment too ;-)

This revision is now accepted and ready to land.Apr 14 2023, 9:58 PM
This revision was landed with ongoing or failed builds.Apr 15 2023, 8:07 PM
This revision was automatically updated to reflect the committed changes.

X86, AArch64 and ARM made similar change in D52125 to make hwasan test pass.