This is an archive of the discontinued LLVM Phabricator instance.

Introduce RThreadAccess pass
Needs ReviewPublic

Authored by yrouban on Jun 14 2023, 4:54 AM.

Details

Summary

If the option -rthread-register=<register-name> is specified then:

  • Protect rthread register from register allocation.
  • Add rhread register as a base pointer to pointer operand of load and store instructions if the pointer operand has addrspace(X), where X is specified with -rthread-addrspace option (256 by default).

This pass might be useful for Thread Local Access operations with a dedicated TLS register.

RThreadAccess is added to X86 and AArch64 pipeline in addPreISel() and can be added to other targets as needed.

Diff Detail

Unit TestsFailed

Event Timeline

yrouban created this revision.Jun 14 2023, 4:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 14 2023, 4:54 AM
yrouban requested review of this revision.Jun 14 2023, 4:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 14 2023, 4:54 AM
Herald added a subscriber: wdng. · View Herald Transcript
arsenm added inline comments.Jun 14 2023, 6:42 PM
llvm/include/llvm/Transforms/Scalar/RThreadAccess.h
39

global option codegen options like this are bad. If this is for more than debugging it should be a function attribute or something

Would this be better served with an intrinsic to read this register? Does the register need to be globally reserved or just within the local function?

Would this be better served with an intrinsic to read this register? Does the register need to be globally reserved or just within the local function?

Actually this new pass RThreadAccess generates reading the rthread register with @llvm.read_register().
I believe that, the easiest rule would be to reserve the rthread register for all functions (in one module at least). This allow to not think if this register can be changed or not by other functions called.
So I'm thinking if it would be ok to set these options as module level metadata instead of cl::opt.

Would this be better served with an intrinsic to read this register? Does the register need to be globally reserved or just within the local function?

Actually this new pass RThreadAccess generates reading the rthread register with @llvm.read_register().

Right, this is the ugly thing I'm trying to guide you away from doing but need to understand exactly what the constraints are on the register. An intrinsic with a defined meaning is better than an unrestricted register read

Right, this is the ugly thing I'm trying to guide you away from doing but need to understand exactly what the constraints are on the register. An intrinsic with a defined meaning is better than an unrestricted register read.

Thank you. An excuse for reading register is that it is done in the very late stage of the pipeline and is almost target agnostic.

Right, this is the ugly thing I'm trying to guide you away from doing but need to understand exactly what the constraints are on the register. An intrinsic with a defined meaning is better than an unrestricted register read.

Thank you. An excuse for reading register is that it is done in the very late stage of the pipeline and is almost target agnostic.

I find the areas where people try to bypass the normal legalization process difficult to follow and implement. I think expecting to parse meaning out of an unrestricted read and a side channel to try to interpret it is more difficult to deal with rather than something higher level