This is an archive of the discontinued LLVM Phabricator instance.

[X86] Improve diagnostics for named registers
AbandonedPublic

Authored by e-kud on Jun 6 2023, 7:32 PM.

Details

Reviewers
pengfei
RKSimon
Summary

Closes #62984

Diff Detail

Event Timeline

e-kud created this revision.Jun 6 2023, 7:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 6 2023, 7:32 PM
e-kud updated this revision to Diff 529954.Jun 9 2023, 7:07 AM

Rebased

e-kud published this revision for review.Jul 11 2023, 6:06 AM
e-kud added reviewers: pengfei, RKSimon.
e-kud added a subscriber: RKSimon.

Hi @pengfei @RKSimon, what do you think about such diagnostic improvement? It works perfectly with clang, however llc ignores errors in a handler and continues execution. It seems that we need a combination of diagnostic and report_fatal_error to stop both clang and llc. Or is it expected behavior of llc?

Herald added a project: Restricted Project. · View Herald TranscriptJul 11 2023, 6:06 AM

I think the expected behavior is to diagnostic this problem from the front end. I didn't look into details, but guess you may be able to do it in SemaChecking.cpp.

Maybe the obstacle is we cannot get FP infor at the time.

e-kud abandoned this revision.Aug 30 2023, 11:49 AM

I think the expected behavior is to diagnostic this problem from the front end. I didn't look into details, but guess you may be able to do it in SemaChecking.cpp.

Maybe the obstacle is we cannot get FP infor at the time.

Generally the problem is that front end is too early for the diagnostic.

E.g. for the following two functions we should get the diagnostic only for the second. Because the first function will emit frame pointer and accessing rbp is valid. Also some optimizations may influence on presence of the frame pointer.

int register x __asm("ebp");
int square0(int num) {
    int y[num];
    bar(y);
    return x * num;
}
int register x __asm("ebp");
int square1(int num) {
    return x * num;
}

BUT, we still can handle it in front end. We may be more strict: if a global register variable on the frame pointer register is used in a statement, we should check -fno-omit-frame-pointer applied to statement's context. -fno-omit-frame-pointer is a guarantee that variable can be on rbp register.

I actually have no idea how to implement it in FE due to unfamiliarity with it. BTW, AArch64 simply miscompiles without any error.

Abandon revision for the better times