Lawrence, Peter via llvm-dev
2016-Jul-13 19:26 UTC
[llvm-dev] IPRA, interprocedural register allocation, question
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>
Mehdi Amini via llvm-dev
2016-Jul-13 19:40 UTC
[llvm-dev] IPRA, interprocedural register allocation, question
> 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. > > 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] > 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/c43ad9ac/attachment.html>
Mehdi Amini via llvm-dev
2016-Jul-13 19:42 UTC
[llvm-dev] IPRA, interprocedural register allocation, question
> On Jul 13, 2016, at 12:40 PM, Mehdi Amini <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: >> >> 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, > > 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.What I meant here is: you don’t *have to* use LTO (especially if you don’t use a linker right now), but it is an existing mechanism to achieve what you want. So somehow you need to accomplish the same thing (I.e. mark as many functions as possible “internal”). The best way to implement it is very dependent on your workflow. — Mehdi> > — > 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 <mailto:vivekvpandya at gmail.com>] >> Sent: Wednesday, July 13, 2016 11:47 AM >> To: Lawrence, Peter <c_plawre at qca.qualcomm.com <mailto:c_plawre at qca.qualcomm.com>> >> Cc: mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>; llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>; llvm-dev-request at lists.llvm.org <mailto:llvm-dev-request at lists.llvm.org>; Hal Finkel <hfinkel at anl.gov <mailto: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/0befd77c/attachment.html>
vivek pandya via llvm-dev
2016-Jul-14 04:50 UTC
[llvm-dev] IPRA, interprocedural register allocation, question
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 ofthis 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>
vivek pandya via llvm-dev
2016-Jul-14 11:19 UTC
[llvm-dev] IPRA, interprocedural register allocation, question
On Thu, Jul 14, 2016 at 4:01 PM, zan jyu Wong <zyfwong at gmail.com> wrote:> Vivek, > > First of all, I'd like to thank you for you hard work. Your work really > helps me a lot. >Thanks Zan Jyu Wong I am glad that this helped, but I would like to share credits with my mentors and llvm community who have helped me for this. I am adding llvm dev list here because if my reasons are wrong then some can help both of us understanding it correctly. But I have a question about regmask collector.> In lib/CodeGen/RegUsageInfoCollector.cpp, there's a for-loop to iterator > over all registers to check > if they are modified: > for (unsigned PReg = 1, PRegE = TRI->getNumRegs(); PReg < PRegE; ++PReg) > if (MRI->isPhysRegModified(PReg, true)) > markRegClobbered(TRI, &RegMask[0], PReg); > > void RegUsageInfoCollector::markRegClobbered(const TargetRegisterInfo *TRI, > uint32_t *RegMask, unsigned > PReg) { > // If PReg is clobbered then all of its alias are also clobbered. > for (MCRegAliasIterator AI(PReg, TRI, true); AI.isValid(); ++AI) { > DEBUG(dbgs() << "mark: " << TRI->getName(*AI) << "\n"); > RegMask[*AI / 32] &= ~(1u << (*AI % 32)); > } > } > > Suppose that r0, r1 is sub-regs of d0. And function use only r0. Then both > r0, d0 will return true > when call with MRI->isPhysRegModified. When call `markRegClobbered' using > d0, r1 will mark as clobbered, too. > But I don't think that r1 should marked as clobbered. > > I'm wondering that if this is expcted behavior? Thanks again. >No I don't think that r1 will be clobbered here. My reasons are as follow with slightly different example : Consider AL | AH | AX | EAX | RAX and the way LLVM models this register so that AL is aliased to AX, EAX and RAX similar for AH. This can be verified from lib/Target/X86/X86RegisterInfo.td file consider following comments from the file : // In the register alias definitions below, we define which registers alias // which others. We only specify which registers the small registers alias, // because the register file generator is smart enough to figure out that // AL aliases AX if we tell it that AX aliased AL (for example). see definitions of registers like def AL : X86Reg<"al", 0>; def AH : X86Reg<"ah", 4>; def AX : X86Reg<"ax", 0, [AL,AH]>; ... So if we mark AX as used/modified than obviously we can't use AL or AH but yes if only AL is clobbered than AH can still be used. I hope this helps, and llvm devs please correct me if necessary. -Vivek> > On Thu, Jul 14, 2016 at 12:50 PM, vivek pandya via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> 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 >>> >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160714/195f076a/attachment-0001.html>
Mehdi Amini via llvm-dev
2016-Jul-14 17:58 UTC
[llvm-dev] IPRA, interprocedural register allocation, question
Just to clarify, because I don't know your exact build flow, LLVM has the internalize pass that can turn all (controlled with a whitelist optionally) symbols static without having to change the source. -- Mehdi Sent from my iPhone> On Jul 14, 2016, at 10:48 AM, Lawrence, Peter <c_plawre at qca.qualcomm.com> wrote: > > Mehdi, > 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> 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. > > 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/d780c726/attachment.html>
Lawrence, Peter via llvm-dev
2016-Jul-15 17:49 UTC
[llvm-dev] IPRA, interprocedural register allocation, question
Mehdi,
Many thanks, this really helps me understand “the llvm way”
--Peter Lawrence.
From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Thursday, July 14, 2016 10:58 AM
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
Just to clarify, because I don't know your exact build flow, LLVM has the
internalize pass that can turn all (controlled with a whitelist optionally)
symbols static without having to change the source.
--
Mehdi
Sent from my iPhone
On Jul 14, 2016, at 10:48 AM, Lawrence, Peter <c_plawre at
qca.qualcomm.com<mailto:c_plawre at qca.qualcomm.com>> wrote:
Mehdi,
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>
[mailto:mehdi.amini at apple.com]
Sent: Wednesday, July 13, 2016 12:42 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at
qca.qualcomm.com>>
Cc: vivek pandya <vivekvpandya at gmail.com<mailto:vivekvpandya at
gmail.com>>; llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>; llvm-dev-request at
lists.llvm.org<mailto:llvm-dev-request at lists.llvm.org>; Hal Finkel
<hfinkel at anl.gov<mailto: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:
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,
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/20160715/b40d500d/attachment.html>