I'm adding support for -ffixed-<reg> <http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435> 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. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121002/c8f00356/attachment.html>
On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote:> I'm adding support for -ffixed-<reg> 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.What "-ffixed-<reg>" does? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
On 10/2/2012 9:36 AM, 陳韋任 (Wei-Ren Chen) wrote:> On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote: >> I'm adding support for -ffixed-<reg> 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. > What "-ffixed-<reg>" does? > > Regards, > chenwj >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. Matthew C -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121002/5e3bd400/attachment.html>
On Oct 2, 2012, at 7:23 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:> I'm adding support for -ffixed-<reg> 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.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-<reg> to work with LTO. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121002/822f09f0/attachment.html>
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 -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
On 10/3/2012 12:29 AM, Chris Lattner wrote:> On Oct 2, 2012, at 7:23 AM, Matthew Curtis <mcurtis at codeaurora.org > <mailto:mcurtis at codeaurora.org>> wrote: >> I'm adding support for -ffixed-<reg> >> <http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435> >> 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. > > 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-<reg> to work with LTO.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. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121003/6b782986/attachment.html>