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

vivek pandya via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 13 11:46:35 PDT 2016


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


On Wed, Jul 13, 2016 at 1:25 AM, Lawrence, Peter <c_plawre at qca.qualcomm.com>
wrote:

> Mehdi,
>
>             In my mind at least, “whole program” means no dynamic
> libraries, so the only
>
> external functions are simple runtime support, do you have a suggested
> term for that ?
>
>
>
> --Peter.
>
>
>
>
>
>
>
> *From:* mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
> *Sent:* Tuesday, July 12, 2016 12:31 PM
> *To:* Lawrence, Peter <c_plawre at qca.qualcomm.com>
> *Cc:* vivek pandya <vivekvpandya at gmail.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
>
>
>
>
>
> On Jul 12, 2016, at 12:20 PM, Lawrence, Peter <c_plawre at qca.qualcomm.com>
> wrote:
>
>
>
> Mehdi,
>
>              I am looking for an understanding of   1) IPRA in general,
>   2) IPRA in LLVM.
>
> Whether I want to use LTO or not is a separate issue.
>
>
>
> 1)  I currently believe it is a true statement that:
>
>                 If all external functions are known to not call back into
> the “whole-program”
>
>                 Being compiled, then IPRA is free to do anything at all to
> the functions being
>
>                 Compiled, not limited to only “upgrades” calling
> convention changes, but
>
>                 Also allowing “downgrades” calling convention changes as
> well.
>
>
>
> Do you think my current belief #1 is correct ?
>
>
>
> Yes, with some extra assumptions (you don’t use dlsym for instance, and
> you won’t link to another file with a global initializer that can call any
> of these).
>
>
>
> I expressed this earlier (which include the other issues I mentioned just
> before) as “we can turn the linkage of every function into local” (or
> private, or static, whatever denomination you prefer).
>
>
>
>
>
> 2) it seems that LLVM currently limits itself to “upgrades” calling
> convention changes,
>
> The reason being so that not all call sites are required to be changed,
>
> therefore calls through function pointers can use the default calling
> convention
>
> If for example there is insufficient analysis to know for sure what
> functions can be
>
> called from that site.
>
>
>
> Is my understanding #2 of IPRA in LLVM correct ?
>
>
>
>
>
> I don’t believe this is correct, currently IPRA will limit itself to this
> for function that can be called from another module.
>
> I will freely change the calling convention, including downgrades, when it
> knows that it can see all call sites (+ extra conditions, like no recursion
> being involved I think).
>
>
>
>
>
>
>
> “whole-program” here is a misnomer since there are external functions, but
> I don’t
>
> Have a better term for this.
>
>
>
> I believe you can talk about “main module”, i.e. the module defines the
> entry point for the program.
>
> Note LLVM can’t make assumption about the lack of dlsym() or global
> initializer in other module for example, so the linkage type of functions
> is what tells us about the possibility to call back or not.
>
>
>
>
>
>>
> Mehdi
>
>
>
>
>
>
>
>
>
> “upgrades” means some scratch regs are converted to save
>
> (the callee either doesn’t touch them at all, or does do save/restore)
>
> “downgrades” means some save regs are converted to scratch
>
>                 (the callee no longer does save/restore to some registers,
> and does clobber them)
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160714/1c765363/attachment.html>


More information about the llvm-dev mailing list