This is an archive of the discontinued LLVM Phabricator instance.

[LoongArch] Add back SDNPSideEffect properties to CSR and IOCSR read ops
ClosedPublic

Authored by xen0n on Jun 27 2023, 5:52 AM.

Details

Summary

In general, CSR and IOCSR reads should be treated as volatile because:

  • there may well be intervening writes between seemingly common expressions;
  • the stateful entity behind a given (IO)CSR may well be volatile.

Confirmed to fix broken Clang Linux/LoongArch builds (dying when a
userspace process tries to use FPU, panicking when that process happens
to be PID 1) with this patch.

Fixes: https://github.com/llvm/llvm-project/issues/63549
Fixes: 2efdacf74c54 ("[LoongArch] Add missing chains and remove unnecessary SDNPSideEffect property for some intrinsic nodes")

Diff Detail

Event Timeline

xen0n created this revision.Jun 27 2023, 5:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2023, 5:52 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
xen0n requested review of this revision.Jun 27 2023, 5:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2023, 5:52 AM

But it's puzzling. Is reading a CSR really a side effect?

xen0n edited the summary of this revision. (Show Details)Jun 27 2023, 6:06 AM

But it's puzzling. Is reading a CSR really a side effect?

I didn't look deeper regarding how to best model this (effectively I'm just reverting some changes), but the crux is that (IO)CSR reads should in general be treated as volatile.

Ah, in the C standard "reading a volatile variable" is indeed a side effect. I must have been thinking about another definition of "side effect".

But should we do it for movfcsr2gr as well? It cannot be reordered with any floating-point arithmetic instructions.

Interesting. Does cpucfg have the same issue?

Interesting. Does cpucfg have the same issue?

As at now all cpucfg info seem constant.

xen0n added a comment.Jun 27 2023, 6:31 AM

Interesting. Does cpucfg have the same issue?

In theory CPUCFG data could be altered by writing to certain model-specific CSRs, but I don't think it's worthwhile to make it volatile too, because no kernel should be doing that under the hood (at most do this once before starting even PID1; in fact no known LoongArch OSes do this).

xen0n added a comment.Jun 27 2023, 6:37 AM

Ah, in the C standard "reading a volatile variable" is indeed a side effect. I must have been thinking about another definition of "side effect".

But should we do it for movfcsr2gr as well? It cannot be reordered with any floating-point arithmetic instructions.

Ah indeed. There are Flags and Cause fields that are effectively, flag bits. FCSR reads should be free of side-effects but reordering indeed should get inhibited, I think it's probably better to deal with that in a separate patch.

hev accepted this revision.Jun 27 2023, 6:39 AM
This revision is now accepted and ready to land.Jun 27 2023, 6:39 AM
xen0n added a comment.Jun 27 2023, 6:40 AM

Interesting. Does cpucfg have the same issue?

In theory CPUCFG data could be altered by writing to certain model-specific CSRs, but I don't think it's worthwhile to make it volatile too, because no kernel should be doing that under the hood (at most do this once before starting even PID1; in fact no known LoongArch OSes do this).

Another reason why changing CPUCFG is effectively never done: the MCSRs are entirely undocumented (the only existence being in the kernel sources and semantics only narrowly and anecdotally dispersed), thus unreliable to depend on.

xen0n edited the summary of this revision. (Show Details)Jun 27 2023, 6:43 AM
xen0n edited the summary of this revision. (Show Details)
xen0n edited the summary of this revision. (Show Details)
SixWeining accepted this revision.Jun 27 2023, 6:44 AM
xen0n updated this revision to Diff 534969.Jun 27 2023, 7:06 AM

Update some missed test fixtures.

This revision was landed with ongoing or failed builds.Jun 27 2023, 5:27 PM
This revision was automatically updated to reflect the committed changes.

LGTM. This patch prevents DeadMachineInstructionElim from removing the instructions with unmodeled side effects.