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

[Lawrence, Peter via llvm-dev]

Vivek,
             I am looking into these function attributes in the clang docs
                Preserve_most
                Preserve_all
They are not available in the 3.6.2 that I am currently using, but I hope they exist in 3.8

These should provide enough info to solve my problem,
at the MC level calls to functions with these attributes
with be code-gen’ed  through different “calling conventions”,
and CALL instructions to them should have different register USE and DEF info,

This CALL instruction register USE and DEF info should already be useful
to the intra-procedural register allocator (allowing values live across these
calls to be in what are otherwise caller-save registers),
at least that’s how I read the MC dumps, every call instruction seems to have
every caller-save register flagged as “imp-def”, IE implicitly-defined by the instruction,
and hopefully what is considered a caller-save register at a call-site is defined by the callee.
And this should be the information that IPRA takes advantage of in its bottom-up analysis.


Which leads me to this question, when compiling an entire whole program at one time,
so there is no linking and no LTO, will there ever be IPRA that works within LLC for this scenario,
and is this an objective of your project, or are you focusing only on LTO ?


I know this is not the typical “linux” scenario (dynamic linking of not only standard libraries,
but also sometimes even application libraries, and lots of static linking because of program
size), but it is a typical “embedded” scenario, which is where I am currently.


Other thoughts or comments ?


--Peter Lawrence.


From: vivek pandya [mailto:vivekvpandya at gmail.com]
Sent: Wednesday, July 06, 2016 2:09 PM
To: llvm-dev <llvm-dev at lists.llvm.org>; llvm-dev-request at lists.llvm.org; Lawrence, Peter <c_plawre at qca.qualcomm.com>
Subject: Re:[llvm-dev] IPRA, interprocedural register allocation, question

Hello Peter,

Thanks to pointing out this interesting case.
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.
If inline asm template has specified clobbered list properly than IPRA is able to use that information and it propagates correct register mask (and that also means that skipping clobbers list while IPRA enabled may broke executable)
For example in following code:
int gcd( int a, int b ) {
    int result ;
    /* Compute Greatest Common Divisor using Euclid's Algorithm */
    __asm__ __volatile__ ( "movl %1, %%r15d;"
                          "movl %2, %%ecx;"
                          "CONTD: cmpl $0, %%ecx;"
                          "je DONE;"
                          "xorl %%r13d, %%r13d;"
                          "idivl %%ecx;"
                          "movl %%ecx, %%r15d;"
                          "movl %%r13d, %%ecx;"
                          "jmp CONTD;"
                          "DONE: movl %%r15d, %0;" : "=g" (result) : "g" (a), "g" (b) : "ecx" ,"r13", "r15"
    );

    return result ;
}
IPRA calculates and propagates correct regmask in which it marks CH, CL, ECX .. clobbered and R13, R15 is not marked clobbered as it is callee saved and LLVM code generators also insert spill/restores code for them.

Is there any way in your IPRA interprocedural register allocation project that
The user can supply this information for external functions ?
By external word do you here mean function defined in other module than being used?  In that case as IPRA can operate on only one module at time register usage propagation is not possible. But there is a work around for this problem. You can use IPRA with link time optimization enabled because the way LLVM LTO works it creates a big IR modules out of source files and them optimize and codegen it so in that case IPRA can have actual register usage info (if function will be compiled in current module).

In case you want to experiment with IPRA please apply http://reviews.llvm.org/D21395 this patch before you begin.

-Vivek

Perhaps using some form of __attribute__ ?
Maybe __attribute__ ((registermask = ....))  ?


--Peter Lawrence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160708/5e13dc2b/attachment.html>