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

Lawrence, Peter via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 14 10:48:04 PDT 2016

               Bravo, Well done Mr Amini !

Ordinarily I would find adding “static” to all functions objectionable,
We’re doing whole-program compilation and optimization, and don’t
use a linker, so “static” currently doesn’t appear anywhere in our sources.
And I view “static” as not really part of the language, rather more
of a linker directive.   But we really only have a small handful of real-time
performance critical functions, it will be trivial to declare them static.

--Peter Lawrence.

From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Wednesday, July 13, 2016 12:42 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 13, 2016, at 12:40 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote:

On Jul 13, 2016, at 12:26 PM, Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at qca.qualcomm.com>> wrote:

             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).

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

More information about the llvm-dev mailing list