similar to: [LLVMdev] AsmPrinter

Hi, I have a question regarding this method, as i have discovered a case where it seems very far from 'strict'. I had two MI's, A and B, where A is !isSafeToMove(): A B TwoAddress pass changes the order to B A , as it reschedules the LastKill MI (B). Is this a bug in TwoAdress, or is it the case that isSafeToMove() is weaker than isSchedulingBoundary() so that these indirect

A similar setting occurs with ARM Thumb code which for many instructions has a short 2-address encoding and a longer 3 address form. As far as I know this is done by selecting the 3 address form and rewriting them to 2-address after register allocation where possible. See lib/Target/ARM/Thumb2SizeReduction.cpp. - Matthias > On Sep 29, 2015, at 2:22 PM, Quentin Colombet via llvm-dev

Hi, we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag was incorrectly set while it actually shouldn't. The attached patch and test case triggers an assert in TwoAddress.  (bin/llc ./tc_TwoAddr_crash.ll

On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > Tom, > > I do not have your call stack, but packetizer calls > ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is > the first time you use the new MI sched infrastructure (like your target has > not implemented misched yet) there might be some work needed to implement > couple target

Could you please expand a bit? Why are not the MCInstr and MachineInstr classes compatible? Is this not a long term goal, even? Could I make optimization passes in the MC layer with a disassembler as in a MachineFunction? Thanks, Jonas -----Original Message----- From: Eric Christopher [mailto:echristo at apple.com] Sent: Friday, February 17, 2012 8:20 PM To: Jonas Paulsson Cc: LLVMDEV

Hi Tim, Thank you a lot for your reply. So IIUC, optimization passes in opt do not reorder IR instructions, only passes in llc that move MIR instructions around. Is it correct? On the back-end (llc) side, hasSideEffects might prevent some reordering. But I just learn about TargetInstrInfo::isSchedulingBoundary. Can you tell me what are the differences between the two please? Thank you very much

On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: >> Tom, >> >> I do not have your call stack, but packetizer calls >> ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is >> the first time you use the new MI sched infrastructure (like your

Dear guys, I need help fixing a little piece of code. I have a pass that I really want to execute after the TwoAddressinstructionPass. But if I write "AU.addRequiredID(TwoAddressInstructionPassID);" in my pass' getAnalysisUsage, I end up getting the infamous: PassManagerT.h:387: failed assertion `getAnalysisOrNullUp(P) &&

Hi (Jakob), in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a register that gets killed can be reused by another MI - these live ranges do

I found myself wanting a "scheduling barrier" in LLVM. In my specific circumstances I only want it to mean that TargetInstrInfoImpl::isSchedulingBoundary() would return true. I added SchedulingBarrier to MCID in MCInstrDesc.h and pushed it through TD attributes down to isSchedulingBoundary(). Is this something of general interest, or is there another mechanism for implementing

On May 24, 2011, at 8:22 AM, Jonas Paulsson wrote: > Hi (Jakob), > > in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass > prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's > per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a

On Thu, Mar 29, 2012 at 01:50:58PM -0500, Sergei Larin wrote: > Tom, > > What is in your isSchedulingBoundary? If it contains isLabel you might > need to disable that assert: > > assert(!MI->isTerminator() && !MI->isLabel() && > "Cannot schedule terminators or labels!"); > > Sergei Larin > > -- > Qualcomm

Tom, I do not have your call stack, but packetizer calls ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is the first time you use the new MI sched infrastructure (like your target has not implemented misched yet) there might be some work needed to implement couple target hooks. isSchedulingBoundary is one of them. Also try to disable that assert and see what happens. It

> On Aug 30, 2017, at 1:43 PM, Matthias Braun <matze at braunis.de> wrote: > > That means you cannot use the code from RegisterPressure.{cpp|h} to compute this. The other liveness analysis we have in llvm codegen is LiveIntervals (LiveItnervalAnalysis) which gives you a list of liveness segments of a given vreg (the same representation is used in most linear scan allocators even

Hi, I'm working on live intervals and I'm curious about how LLVM typically would represent live info. Take the following case (after SimpleRegisterCoalescer): BB#3: derived from LLVM BB %bb.nph Live Ins: %a0_h Predecessors according to CFG: BB#2 %reg16500<def> = COPY %reg16499 Successors according to CFG: BB#4 BB#4: derived from LLVM BB %for.body21 Live Ins:

Hi, I would be happy to give it a try :-) The fact that AA was added at a later point explains the situation a bit, as much fewer SUs should end up in RejectMemNodes without it. RejectMemNodes is bad in that it mixes all the SUs together again, after having gone through the work of separating them by analyzing their underlying objects. It is also very confusing to have two "stages" of

Hi Jonas, I won’t have time to look at it this week after all. I’ll try to do that next week. If you do not hear back from me by end of next, do not hesitate to ping me! Cheers, -Quentin > On Apr 22, 2015, at 9:32 AM, Quentin Colombet <qcolombet at apple.com> wrote: > >> >> On Apr 21, 2015, at 11:49 PM, Jonas Paulsson <jonas.paulsson at ericsson.com

Thank you Chris. I will try to implement the TwoAddress pass to run on machine code. Why it has not been originally implemented to run on machine code? Is there anything that makes it troublesome after RA has been performed? Could you tell me if the transformations below are correct? 1) a := b op c --> a := b --> a := b a := a op c a

I looked at SplitKit, but I am not sure how to best do it, so it would be great if you could take a look. /Jonas On 2015-04-21 19:35, Quentin Colombet wrote: >> On Apr 21, 2015, at 7:40 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> >> >>> On Apr 21, 2015, at 05:39, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: >>> >>>

On Apr 17, 2013, at 2:33 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, April 17, 2013 12:22:49 AM >> Subject: RE: [LLVMdev] alias analysis in backend