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

[vivek pandya via llvm-dev]

On Thu, Jul 14, 2016 at 1:10 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> 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.
>
> Peter there is no need to apologize as we want to get most benefits out of
this work ( this is our aim for  GSoC project ).
Yes 'regmask' can be useful when you can't exactly describe register usage
with preserve_most/ preserve_all.  I just ask before sending because to
have this feature in truck will take some time (review process).

As far as LLC is concerned what Mehdi has suggested should be enough. Also
I have mentioned already even you want to compile multiple source file and
get benefits with LLC I believe you can use llvm-link to combine all .bc
files to create one module and use resulting .bc file with LLC to get most
benefits of IPRA.

-Vivek

>
> 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
> <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/20160714/192d8408/attachment.html>