search for: getdescent

With a modified copy of LLVM (so it's probably my fault) I'm getting an assertion failure because isTwoAddrUse (in TwoAddressInstructionPass.cpp) is being called with a MachineInstr MI such that MI.getNumOperands() is 2, but MI.getDesc().getNumOperands() is 5. The assertion fails when that function calls MI.getOperand(2). My question is: is isTwoAddrUse doing the right thing here? static

Hi all, I have been experiencing difficulties building R (be this 2.13.1, beta, devel, or rc) on Windows 7 64bit. I believe I am following the manual religiously, and don't think I am doing anything differently from the many successful build attempts in the past. Unzipping the tarball works fine, but when I invoke make, I get (shown for R-rc, same for 2-13.1):

I see strangeness on Thumb TST (tTST) predicate 'isCompare' It is true for regular ARM, false for Thumb: (gdb) p MI->dump() TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:% reg16397 $24 = void (gdb) p MI->getDesc().isCompare() $25 = true (gdb) p MI->dump() tTST %reg16396, %reg16397, pred:14, pred:%reg0, %CPSR<imp-def>; tGPR:%reg16396,16397

Hi everyone, The MachineLICM pass has a heuristic such that, even in low-register-pressure situations, it will refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides this more-customized definition: bool ARMBaseInstrInfo::

On Sep 14, 2010, at 12:09 PM, Gabor Greif wrote: > I see strangeness on Thumb TST (tTST) predicate 'isCompare' > > It is true for regular ARM, false for Thumb: > > (gdb) p MI->dump() > TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:% > reg16397 > $24 = void > (gdb) p MI->getDesc().isCompare() > $25 = true > > > (gdb)

On Dec 14, 2010, at 3:46 PM, Richard Pennington wrote: > Notice that the label $BB0_1 is missing. If I disable filling in the > branch delay slots, I get: Is this with the latest SVN HEAD version of LLVM or some other version? The delay slot filler and many other things have been updated for the Microblaze backend. In particular, the commit r120095 for the MBlaze backend fixed some issues

The Sparc, Microblaze, and Mips code generators implement branch delay slots. They all seem to exhibit the same bug, which is not surprising since the code is very similar. If I compile code with this snippit: while (n--) *s++ = (char) c; I get this (for the Microblaze): swi r19, r1, 0 add r3, r0, r0 cmp r3, r3, r7 beqid r3,

This is a template that takes care of managing plugin registries. I wrote it because I got the distinct feeling I was needlessly reinventing the wheel as I wrote a collector registry. I haven't converted anything else to use it, though. Still, it's orthogonal and has become stable in my usage, so I thought I'd submit it in advance. To get my collector registry going, all I

Hi, I notice that the following recent addition X86::CondCode X86::getCondFromBranch(const MachineInstr &MI) { switch (MI.getOpcode()) { default: return X86::COND_INVALID; case X86::JCC_1: return static_cast<X86::CondCode>( MI.getOperand(MI.getDesc().getNumOperands() - 1).getImm()); } } returns an invalid condition for JCC_2 and JCC_4 conditional opcodes. What is

On Sep 17, 2009, at 6:03 PM, Duncan Sands wrote: > Hi Bill, > >>>> Yeah. The logic will need tweaking for sure. I'm also concerned >>>> about the >>>> _Unwind_resume() call. GCC emits a call site region for it in the >>>> exception >>>> table. We...kind of do that. It looks like it's being included in >>>>

Thanks for the review Gordon. On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com>wrote: > On 2011-10-31, at 17:21, Nicolas Geoffray wrote: > > > Here's a patch to allow a GCStrategy to customize the places where it > wants to insert safe points. I'm not sure who maintains the GC code today > in LLVM (I'd be happy to take ownership, if

On 10/23/12 7:19 PM, Craig Topper wrote: > What function provides the encoding length? X86 in particular is so > difficult to encode that only the old style JIT and the MC Code > Emitter could possibly know how many bytes something takes. The getSize() method of MCInstrDesc which can be fetched from a MachineInstr using the getDesc() method:

On Tue, Nov 17, 2015 at 11:15 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 11/17/2015 12:26 PM, Rail Shafigulin wrote: > >> >> I tried setting >> let mayLoad = 1 { >> class InstrLD .... { >> } >> } >> >> But that didn't seem to work. When I looked at the debug output the >> latency for the load

On Nov 1, 2011, at 4:47 AM, Nicolas Geoffray <nicolas.geoffray at gmail.com> wrote: > Thanks for the review Gordon. > > On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2011-10-31, at 17:21, Nicolas Geoffray wrote: > > > Here's a patch to allow a GCStrategy to customize the places where it wants to insert safe points.

I think even if we did use it, MoveImmediate is intended for instructions that move an immediate into a register rather than into memory. It's supposed to indicate instructions that can be folded with the user of the register by changing the user to an immediate instruction. And it wouldn't be set on an instruction like "addl $0, %eax" or "addl $0, (%ecx)" either since

Hi Evan, Thanks for the answers. I had few more queries though. 1. As far as I was able to understand the Codegen infrastructure, ARMInstrInfo.td file has complete description of the instructions which modify the status flags. For example, we have description for both ADD and ADDS. But the problem is that in LLVM, we have a single "ADD" Instruction. Thus when we do getDesc(add), we get

I am trying to categorize the machine instructions based on associated static (i.e., as encoded in .td file) machine description and the corresponding APIs. I would like to perform appropriate actions based on the kind of instruction in a tool that I am working on. For example, I'd like to distinguish between memop instructions involving immediate vs register. While it appears that I would be

Hi Susan, > 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't > work.... Can you tell from this what I'm doing wrong? > The PBQP allocator is built into the LLVM CodeGen library, so the "-regalloc=pbqp" option is already available in llc. If you've built a copy of the PBQP allocator in a separate library it will try to re-register

Hal, that’s a good point. There are more manually-maintained tables in the X86 backend that should probably be tablegened: the memory-folding tables and ReplaceableInstrs, to name a couple. If you have ideas on how to get these auto-generated, please let us know. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev Sent: Wednesday, November 23, 2016

On Jul 14, 2008, at 5:10 PM, kapil anand wrote: > Hi Evan, > > Thanks for the answers. I had few more queries though. > > 1. As far as I was able to understand the Codegen infrastructure, > ARMInstrInfo.td file has complete description of the instructions > which modify the status flags. For example, we have description for > both ADD and ADDS. But the problem is