llvm dev - Jul 2016 - IPRA, interprocedural register allocation, question

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<mailto: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/20160712/d837082b/attachment.html>

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>

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,

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.

--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/8bd4bb8c/attachment.html>