adding support for -ffixed-<reg>

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