similar to: [LLVMdev] SelectionDAG Preserves IR Order

On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); >

Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions

Thanks that clears things up. So if I want to mess around with how schedules are generated, looking at the MachineScheduler pass is the best place now? -Dilan On Mon, Jul 31, 2017 at 3:24 PM Matthias Braun <mbraun at apple.com> wrote: > > > On Jul 31, 2017, at 2:51 PM, Dilan Manatunga via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > >

Hello. I am using the post-RA (Register Allocation) scheduler to avoid data hazards by inserting other USEFUL instructions from the program (besides NOPs) and it breaks apart some sequences of instructions which should remain "glued" together. More exactly, in my [Target]ISelDAGToDAG.cpp it is possible that I replace for example a BUILD_VECTOR with a machine SDNode called

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent (and necessarily a separate register). The FMA variants have

Good day LLVM-Dev, I hope all are in good health. We are currently implementing the compare operation for i64 type in our target. The main difference of the i64 type compare to lower integer types is that it performs a library call instead of generating a compare instruction. All is good until before ISelDAGToDAG class. We have observed that the difference in a compare operation for i32 and

...this is moving from llvm-commits to llvm-dev. On Feb 10, 2012, at 12:14 PM, Sergei Larin <slarin at codeaurora.org> wrote: > 1) Can a BB presented to the MI scheduler be _not_ terminated (end on a non > terminator MI) under any circumstances? Below you are speaking about "Empty > blocks, or blocks with only a single instruction that not a terminator..." - > What

While looking at why some generated code for SPARC was poor, I ran into the fact that the MachineScheduler is not yet enabled by default -- it's opt in for each target. Having a bunch of deprecatedish code around was a bit confusing for newbie me. So, I suggested on IRC that perhaps it's been long enough by now that any target that hasn't switched over probably isn't actually

I think those should be considered internal options for (llvm codegen) developers, a normal compiler user should not need to use any of them. Of course you can look around the llvm sourcecode (esp. in lib/CodeGen/MachineScheduler.cpp) and see what cl::opt options are available and how they affect the scheduler operation. In case of the MachineScheduler all settings are the same regardless of the

Hello Andy, Thank you for your offer to work together on implementing the your new scheduler on X86. I can start working on this right away. In case you were unaware, the new Silvermont micro-architecture is only out of order on the integer side. The SSE instructions are still in order, so the current postRA scheduler is very beneficial for code with lots of SSE instructions, such as the ISPC

Please tell me whether the following implementation is correct..... My target supports 64 bit mask means immediate(0-2^63) I have implemented it but i dont know whether its correct or not. Please see the changes below that i have made in x86isellowering.cpp static SDValue lower2048BitVectorShuffle(const SDLoc &DL, ArrayRef<int> Mask, MVT VT,

Dear Dev-Team, I am currently in the process of writing my bachelor thesis. The topic is about the implementation and evaluation of trace scheduling in the llvm framework for VLIW architecture. Simplifying the problem, only loop free code will be processed. Further, preparations and studies of llvm framework have shown, that, in my humble opinion, the machineScheduler::runOnMachineFunction()

Hi, I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing). I'm basing the code on the PowerPC version, which itself is based on the X86 version. This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that below), so I know it's close. However, the PowerPC

I'm briefly enabling the MachineScheduler pass for x86 tonight to collect information on any failures that may show up. To properly enable the new scheduler, this hook is implemented in X86Subtarget: bool enableMachineScheduler() const LLVM_OVERRIDE { return true; } The MachineScheduler pass itself can be enabled/disabled with -enable-misched=true/false. But most of the codegen changes

On Mon, Jun 24, 2013 at 2:41 AM, Andrew Trick <atrick at apple.com> wrote: > I'm briefly enabling the MachineScheduler pass for x86 tonight to collect > information on any failures that may show up. > > To properly enable the new scheduler, this hook is implemented in > X86Subtarget: > > bool enableMachineScheduler() const LLVM_OVERRIDE { return true; } > >

Hi Andy, Thanks for the explanations. Yes AMDGPU is in-order and has MicroOpBufferSize = 1. Re "issue limited" and instruction groups: could it make sense to disable the generic scheduler's detection of issue limitation on in-order CPUs, or on CPUs that don't define instruction groups, or some similar condition? Something like: --- a/lib/CodeGen/MachineScheduler.cpp +++

On Jul 31, 2012, at 8:37 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > I'm working on a custom top-down post RA scheduler which builds bundles > at the same time for our VLIW processor. I've borrowed most of the > implementation from the resource priority queue implemented for the > existent VLIW scheduler but applied to the context of MI

I've been using R for several months now, in fact it was my intro to "real" computer programming. It used to frustrate me no end, but lately I've noticed my reaction has changed. Nowadays its much more like "wow, is that cool, or what?". So I guess I've gotten over the hump of the learning curve. Comparing what I now do with R to my previous hodge-podge of

On Jun 24, 2013, at 2:47 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Jun 24, 2013 at 2:41 AM, Andrew Trick <atrick at apple.com> wrote: > I'm briefly enabling the MachineScheduler pass for x86 tonight to collect information on any failures that may show up. > > To properly enable the new scheduler, this hook is implemented in X86Subtarget:

Andy, Jacob, I have ported Hexagon MI scheduler to use the new scheduler infrastructure, but one of my tests triggers an assert in LiveInterval update. On the surface it does not make much sense to me, so I wonder if this is something you readily recognize, before I try to prop it open... The assert is: lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange*