similar to: Register data flow commits

On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote: > > Still I am looking for feedback on RDF part and also if some one is > willing to mentor me. Hi Vivek, Sorry, I missed this email. I wrote the RDF stuff and I'd be happy to help you out with it if you are interested. The idea was to have a utility class that would represent the data flow between registers. The registers

Hi Venu, FWIW, I have a pass that does copy propagation after RA [1] (currently only within a basic block) that should be enabled some time in the not-too-distant future. It has been reviewed and accepted, but I'm currently working on getting a slight change to the MachineOperand representation [2] that should make the copy propagation change much simpler. I believe this change to

Hi Venu, This is happening because there is an implicit def of ECX on the COPY instruction. This was an issue on Hexagon as well. Let me give you some background. There are two kinds of implicit defs (and implicit uses, but I'll refer only to defs for brevity): (1) Those that indicate that some physical register (that is not an operand) is modified by a given instruction (EFLAGS is a good

Hi Geoff/Krzyssztof, Wouldn't the isRenamable() change be required even for the RDF based copy propagation? Maybe Hexagon does not impose ABI/ISA restrictions which require specific registers to be used in specific contexts. Also, if Geoff's copy propagation pass is invoked post-RA wouldn't it need to handle the x86 ISA feature which allows 8 bit/16 bit values to be moved into a

Hi Krzysztof, In one of your earlier emails in this thread you mentioned that you had some changes which add extra aliases for subregisters. Did you mean for X86? And is it extra register units that you added or aliases? I tried adding extra register units for X86 through some changes in CodeGenRegisters.cpp in TableGen but I am seeing a runtime error in one of my test cases possibly due to the

Hi Venu, > On Sep 11, 2017, at 11:00 PM, Raghavan, Venugopal via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Krzysztof, > > Thanks for your reply. > > I agree that adding extra register units for x86 would be the right way to fix this. Do you know if there is a plan to fix this? No concrete plan, no. We've been thinking about for quite some time now, but

Dear Community, I would like to discuss few points to use RDF to extend register remat scope. Mr. Krzysztof and I have started discussion this on private mail. But I think now it would be better to include community. Interested community member kindly previous discussion (at the end of mail) before starting here. After analyzing if RDF can be used for solving Remat, we think that problem with

Hi, I have some questions about the implementation of Software pipeline in MachinePipeliner.cpp. First, in hexagon backend, between MachinePipeliner and regalloc pass, there're some other passes like phi eliminate, two-address, register coalescing, which may change or insert intructions like 'copy' in MBB, and swp kernel loop may be destroyed by these passes. Why not put

Dear professor John Criswell I would like to implement a new instruction scheduling algorithm so that I need the Data flow graph(DFG) is input of the algorithm. Thanks Huy From: John Criswell [mailto:jtcriswel at gmail.com] Sent: Sunday, June 19, 2016 1:25 AM To: huyite; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] data flow graph Dear Huyite, Your question, as

*Vivek Pandya* On Wed, Mar 23, 2016 at 10:28 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote: > >> >> Still I am looking for feedback on RDF part and also if some one is >> willing to mentor me. > > Hello Krzysztof Parrzyszek, I switched to other topic as I felt I don't have enough

Hi - I replied to the original sender only by mistake. Sorry about that. When we started working on the pipeliner, and added it before the scheduler, we also were concerned that the scheduler or other passes would undo the work of the pipeliner. The initial thought was that we would add information (using metadata or some other way like you've suggested) to the basic block to tell the

Hi Vivek, (Mostly responding with AArch64 hints, though anything I happen to know from elsewhere too). On 29 February 2016 at 13:00, vivek pandya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 2. lib/Target/AArch64/AArch64AddressTypePromotion.cpp > As far as I understand this pass promotes sign exertion for 32 bit integer ( > address) and performs calculation on 64 bit number

So what is the status about LiveVariables. Is there a plan to remove it? After searching in old lvm-dev-mails it is mentioned that LiveVariable still exists due to one pass needing it. And a comment in TargetPassConfig.cpp indicates that the pass in question is TwoAddressInstruction: // FIXME: Once TwoAddressInstruction pass no longer uses kill flags, // LiveVariables can be removed

*Vivek Pandya* On Tue, Mar 1, 2016 at 10:23 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Vivek, > > (Mostly responding with AArch64 hints, though anything I happen to > know from elsewhere too). > > On 29 February 2016 at 13:00, vivek pandya via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 2.

Dear all, Please help me to generate DFG(Data flow graph) in LLVM. Best regards, Huy Mobile: +84942976091 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/29fea8f8/attachment.html>

Where is the liveness analysis pass? I have been looking for days but cannot find anything. I just want to know transfer variables in and out of basic blocks, that are calculated using simple data flow equations. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180920/529bce15/attachment.html>

On 4 Oct 2007, at 00:22, Evan Cheng wrote: >> ifeq ($(ARCH),x86) >> LLCBETAOPTION := -regalloc=local -fast -tail-call-opt -tail-call-opt- >> align-stack > Please remove -regalloc=local -fast. We want to test this patch > separately. just did a test with LLCBETAOPTION := -tail-call-opt -tail-call-opt-align-stack this time only SPASS llc-beta fails (comparing with vanilla

> On Sep 10, 2018, at 5:25 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Sep 10, 2018, at 5:11 PM, Preston Briggs <preston.briggs at gmail.com <mailto:preston.briggs at gmail.com>> wrote: >> >> The phi instruction is irrelevant; just the way I think about things. >> The question is if the allocator believes that t0 and t2

Hi, Using Chaitin's approach, removing a copy via coalescing could expose more opportunities for coalescing. So he would iteratively rebuild the interference graph and check for more opportunities. Chaitin was also careful to make sure that the source and destination of a copy didn't interfere unnecessarily (because of the copy alone); that is, his approach to interference was very

On 9/28/2016 1:20 PM, Quentin Colombet wrote: > >> On Sep 28, 2016, at 10:52 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On X86, the registers AX, EAX and RAX all share the exact same register units. In terms of units, there is no difference between these registers. This makes register units insufficient to track liveness, since live AX