[llvm-dev] IPRA, interprocedural register allocation, question

[Mehdi Amini via llvm-dev]

> On Jul 13, 2016, at 12:26 PM, Lawrence, Peter <c_plawre at qca.qualcomm.com> wrote:
> 
> Vivek,
>              I apologize if you took my original email as a request for implementation,
> I meant to be asking what is already available, I think the answer to that
> is the ‘preserves_most’ and ‘preserves_all’ attributes, but I will also
> Use ‘regmask’ if those prove to be too sub-optimal.
>  
> I am still interested in figuring out the necessary and sufficient conditions
> For LLC to do optimal IPRA when given a “whole program”
> (as per my previous definition of “whole program”),
> As opposed to how to accomplish this with LTO,

Easy: mark *all* of your function “static” (or “internal” in LLVM denomination).  

> If you are open to having such discussions, even though your focus
> IIUC is supposed to be LTO, then great.   I think Mehdi is stuck trying
> To convince me to use LTO, but given all the changes I’ve had to make
> To CodeGen (IE outside of my Target sub-dir) for having separate Data and Address
> register sets, I think using LTO is a long term solution that I can’t take
> On just now (IE the svn branch merge problem)
>  
> As one of my old math professors used to say “don’t use a sledge hammer
> To crush a pea”,  to wit  I am only compiling a single source file as an entire whole
> Program and I don’t do any linking, why should I have to use a linker.

Just semantic issue: you need to tell the optimizer what it can and can’t do. In general we can’t assume that the code being optimized or generated won’t be dlopen/dlsym for instance.
Unfortunately I’d prefer everything to be hidden/private by default and the user having to explicitly export symbols, but that’s not the current model.

The LTO API is here to circumvent this issue: by delaying the optimizations/codegen to the link time, we have more information about what function can / can’t be called from another module. 
One of the key point of LTO is the linker telling us “I don’t need to export this symbol” and we turn it into an “internal” one.

— 
Mehdi



>  
> --Peter Lawrence
>  
>  
> Vivek,
>           I have an application where many of the leaf functions are
> Hand-coded assembly language,  because they use special IO instructions
> That only the assembler knows about.  These functions typically don't
> Use any registers besides the incoming argument registers, IE they don't
> Need to use any additional callee-save nor caller-save registers.
> 
> Perhaps using some form of __attribute__ ?
> Maybe __attribute__ ((registermask = ....))  ?
> 
> 
> --Peter Lawrence.
>  
>  
>  
>  
>  
> From: vivek pandya [mailto:vivekvpandya at gmail.com] 
> Sent: Wednesday, July 13, 2016 11:47 AM
> To: Lawrence, Peter <c_plawre at qca.qualcomm.com>
> Cc: mehdi.amini at apple.com; llvm-dev <llvm-dev at lists.llvm.org>; llvm-dev-request at lists.llvm.org; Hal Finkel <hfinkel at anl.gov>
> Subject: Re: [llvm-dev] IPRA, interprocedural register allocation, question
>  
> Hello Peter,
>  
> Are you still interested in __attribute__(regmask) ? 
> I have done some hack ( both clang+IPRA)  to get it working if you want to play around it I can send a patch by tomorrow.
>  
> Sincerely,
> Vivek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160713/c43ad9ac/attachment.html>