similar to: [LLVMdev] Asserts in bundleWithPred() and bundleWithSucc()

On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > I have a question about the following (four) asserts recently added in > bundleWithPred() and bundleWithSucc() (see below). What is the real danger > of reasserting a connection even if it already exist? The intention was to identify code that may have been converted from the old style a

Jakob, > The intention was to identify code that may have been converted from > the old style a little too quickly. I wanted to avoid bugs from a > global s/setIsInsideBundle/bundleWithPred/g search and replace. This is a good intent. Maybe a bit temporal but sound nevertheless. > finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, > LastMI)' which ought to

On Feb 4, 2013, at 8:59 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> The intention was to identify code that may have been converted from >> the old style a little too quickly. I wanted to avoid bugs from a >> global s/setIsInsideBundle/bundleWithPred/g search and replace. > > This is a good intent. Maybe a bit temporal but

Jakob, >... In this case you should either erase the old BUNDLE first, or unbundle it > from the instructions you are trying to finalize. This is exactly my point - I have to unbundle everything to re-bundle it back in :) ...but this case is trivial and I am OK with it. What is more unclear to me is this. How do you use Bundle.insert(I, MI->removeFromBundle()) Where MI == Bundle.End?

On Feb 4, 2013, at 3:02 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> ... In this case you should either erase the old BUNDLE first, or unbundle > it >> from the instructions you are trying to finalize. > > This is exactly my point - I have to unbundle everything to re-bundle it > back in :) ...but this case is trivial and I am

On Feb 4, 2013, at 3:44 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Seems like an easy solution for this case... But let me ask you a more > general question. > The reason I kept on hanging on to the MBB->splice was (probably outdated) > assumption that it will one day properly update liveness for instructions it > moves... That is a serious matter

Jakob, Seems like an easy solution for this case... But let me ask you a more general question. The reason I kept on hanging on to the MBB->splice was (probably outdated) assumption that it will one day properly update liveness for instructions it moves... That is a serious matter for what I am trying to do (global code motion in presence of bundles). What is the current thinking? Will

Hi, I am trying to build the code that I've checked out from the svn repository (revision 175705). I can do make, but not make check, it reports the `No site specific configuration available!' error. Output of make check: llvm[0]: Running test suite make[1]: Entering directory `/home/ppenzin/tmp/llvm/build_x86-64/test' Making LLVM 'lit.site.cfg' file... Making LLVM unittest

Jakob, Consider a counterexample. In a late pass I speculatively move instructions between BBs to improve code density and handle some peculiar back end specific situations which could not be handled in earlier passes. I move instructions one at a time. Currently I do it in a worklist fashion - I collect several possible candidates, and then actually move one. Some moves are _speculative_. Next

Hi, The insertion of DBG_VALUE instructions for spills does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essentially means that if we start with a set of bundled instructions: MI1 [BundledSucc=true, BundledPred=false] MI2 [BundledSucc=false,

Hi again, Here is a small patch to fix this issue. Please note that since the problem results in broken bundles, it can result in invalid schedules for any VLIW back-ends using bundling to group instructions. Best regards Saurabh Verma From: Verma, Saurabh Sent: Tuesday, December 19, 2017 4:14 PM To: llvm-dev at lists.llvm.org Subject: DBG_VALUE insertion for spills breaks bundles Hi, The

Hi, I am looking at the Hexagon MI Scheduling and trying to adapt it to my target. As far as I can see, Hexagon does not bundle the VLIW-bundles by calling bundleWithPred() on MIs of the completed cycle. First of all, why is this not done? SlotIndexes seems to have at least some support for this, by calling getBundleStart() for each MI that is looked up. A follow up question is then, how would

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

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

Sergei, Thank you for your attention. My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details. I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and

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

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of

Hello. I am having difficulties to bundle MachineInstr instructions, before register allocation (RA). More exactly, I registered a simple pass in addPreRegAlloc() that is trying to create bundles. I see that it is written at http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles: <<Packing / bundling of MachineInstr’s should be done as part of the register

On 10/27/2016 4:33 PM, Matthias Braun via llvm-dev wrote: > > In fact I am not sure why you would even wait with the finalization and do it > in a separate pass rather than doing it immediately after forming the bundle. > Using the pass today does not even work as the MachineVerifier will reject the > intermediate unfinalized state (missing internal read markers). I'd suggest to