<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Oct 2, 2012, at 7:23 AM, Matthew Curtis <<a href="mailto:mcurtis@codeaurora.org">mcurtis@codeaurora.org</a>> wrote:</div><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<div bgcolor="#FFFFFF" text="#000000">
I'm adding support for <a href="http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435">-ffixed-<reg></a>
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.<br></div></blockquote></div><br><div>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.</div><div><br></div><div>From the design perspective, I think it would make sense to represent this in LLVM IR with named metadata (<a href="http://llvm.org/docs/LangRef.html#namedmetadatastructure">http://llvm.org/docs/LangRef.html#namedmetadatastructure</a>) 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).</div><div><br></div><div>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.</div><div><br></div><div>-Chris</div></body></html>