[LLVMdev] adding support for -ffixed-<reg>

[Matthew Curtis]

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>