I’m adding support for -ffixed- for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for support.
Any opinions?
Matthew Curtis.
What "-ffixed-<reg>" does?
Regards,
chenwj
From the GCC manual () Useful when writing kernel code or other low-level code (e.g. a VM) where you want to reserve a particular register for your own use. Matthew C
From the GCC manual (http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/
Code-Gen-Options.html#index-ffixed-2267)-ffixed-reg
Treat the register named reg as a fixed register; generated code should
never refer to it (except perhaps as a stack pointer, frame pointer or in
some other fixed role).reg must be the name of a register. The register names accepted are
machine-specific and are defined in the REGISTER_NAMES macro in the machine
description macro file.Useful when writing kernel code or other low-level code (e.g. a VM) where you
want to reserve a particular register for your own use.
Ya, I saw people writing VM often ask for this functionality on ML.
But I have a question, what the difference between this and global
register [1]? To me, they both seems to reserve particular register
from being used by the compiler. If they're the same, I remember Chris
objected to add global register feature in LLVM.
Regards,
chenwj
[1] http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt
The two features are often used together. -ffixed-reg must usually be passed to other compilation units in a program that don't actually use a given global register, or to ensure that it is not used by preceding function definitions.[1]
Global registers imply some level of language/IR support.
In the absence of global register support, use of the register must be written outside of the compiler (e.g. in assembly).
Cheers,
Matthew C.
[1] http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Global-Reg-Vars.html#Global-Reg-Vars
It would be great to have this as a target-indepentent (well, obviously the specific register names are target specific, you know what I mean) compiler feature. This is one of the blocking issues preventing some portion of the Linux kernel from “just working” with LLVM.
From the design perspective, I think it would make sense to represent this in LLVM IR with named metadata (http://llvm.org/docs/LangRef.html#namedmetadatastructure) like “!llvm.fixedregs”. This could then be picked up by the code generator, installed as preallocated registers (Jakob would be the one to ask how best to do this).
If you’re not in a huge hurry, an even better way to model this is with Bill Wendling’s work on generalized function attributes. Our eventual goal is to allow arbitrary target-specific function attributes. Modeling this list as a per-function attribute would be much cleaner, and allow -ffixed- to work with LTO.
-Chris
Hi Chris,
From the design perspective, I think it would make sense to represent this in
LLVM IR with named metadata (http://llvm.org/docs/LangRef.html#
namedmetadatastructure) like "!llvm.fixedregs". This could then be picked up
by the code generator, installed as preallocated registers (Jakob would be the
one to ask how best to do this).
-ffixed-<reg> and global register seems do the same thing, they both
reserve register from being used by the compiler. IIRC, you don't want
to add global register support before. If so, why would you think
-ffixed-<reg> is O.K.?
Regards,
chenwj
We currently have a working solution that satisfies the needs of our internal users, so we’re not in a huge hurry. Depending on the timeline for generalized function attributes, I’d like to pursue this as the preferred solution. I will follow-up with Bill. Thanks, Matthew Curtis.
I'm not opposed to implementing support for global register variables, we just didn't have a way to model it well before. Now we do!
-Chris
I see. Cool!
Cheers,
chenwj