similar to: [LLVMdev] Instruction scheduling barrier

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

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 Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >> >> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most

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

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

Hi, Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget.

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

On Nov 27, 2012, at 11:51 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen?

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen

Setting the MI as isTerminator should have the same impact, yes? I'm not sure of the other consequences of this though, if any, have to look into it. Thanks. -Ryan On Tue, Nov 15, 2016 at 5:18 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > You can override TargetInstrInfo::isSchedulingBoundary for that. > > -Krzysztof > > On 11/15/2016 4:13 PM, Ryan

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 Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: Tom Stellard

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

Hello, I am developing compiler for the 8-bit PicoBlaze processor in LLVM 2.9. The problem at hand is that the stack spilling code in this architecture modifies the machine FLAGS register (i.e. globally visible state). The LLVM core code does not know about this 'feature' and happily inserts spilling code anywhere it wants, thus (potentially) corrupting live FLAGS. Practically, the FLAGS

Hi Tom, We also ran into the same issue when packetizing for Hexagon. Let me try to explain the problem: The scheduler breaks down a basic block into regions (look at MachineScheduler.cpp) - I believe for efficiency. There is an API isSchedulingBoundary to check if an instruction is a scheduling boundary or not. If it is a scheduling boundary, all existing instructions in the region are

Thanks for your response Chuck. >From this and the other responses to my question, it looks like I'm including all the right object files, so it must be something with Visual Studio stripping "dead" code. So, given your response Chuck, I have a few questions. First, what exactly is the code that VStudio seems to be stripping? I might be able to figure out how to prevent it

I have mixed feeling about this. While this does separate out target-independent pieces into CodeGen, it also introduces some confusion where the default implementation is in CodeGen while target overridden version are in Target. I also hate to see all these Target* classes being moved to CodeGen. I thought our solution to this issue is classes such as TargetInstrInfoImpl. What's wrong with

On Thu, Mar 29, 2012 at 03:51:10PM -0700, Andrew Trick wrote: > > 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

Doh. I missed the list in my first reply... Here's the replay of the conversation: ----- Renato: On 10 August 2015 at 14:05, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > --> %SP<def,tied1> = t2LDMIA_RET %SP<tied0>, pred:8, pred:%CPSR, > %R7<def>, %PC<def>, %SP<imp-use,undef>, %R7<imp-use,undef>, >

Hello, The function ARMBaseInstrInfo::AnalyzeBranch contains the following piece of code: } else if (I->isReturn()) { // Returns can't be analyzed, but we should run cleanup. CantAnalyze = !isPredicated(I); } else { This could lead to cases where for a block that ends with a conditional return, AnalyzeBranch returns false (i.e. analyzed), both TBB and FBB are

On Mon, Aug 22, 2016 at 11:40 AM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Aug 22, 2016, at 11:20, Phil Tomson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > We improved our instruction itineraries and now we're seeing our > testcases for fence instructions break. > > > > For example, we have this testcase: > >