similar to: [LLVMdev] possible thumb bug in constant islands

On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > I don't know ARM hardly at all but... > > This comment does not seem to match the code. > Or maybe tBfar is a BL? What does the definition of tBfar say? > > Also, how does this work if the destination is greater than 2**21? > It doesn’t. IIRC, that’s under the category of “if people start

On 11/18/2013 06:34 PM, Jim Grosbach wrote: > On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > >> I don't know ARM hardly at all but... >> >> This comment does not seem to match the code. >> Or maybe tBfar is a BL? > What does the definition of tBfar say? Okay.. but // Far jump // Just a pseudo for a tBL instruction. Needed

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

Evan, et al., I've come across a small issue when using the if conversion pass in PPC to generate conditional returns. Here's a small example: ** Before if conversion ** BB#0: derived from LLVM BB %entry %R3<def> = LI 0 %CR0<def> = CMPLWI %R3, 0 BCC 68, %CR0, <BB#3> Successors according to CFG: BB#3(16) BB#1(16) BB#1: derived from LLVM BB

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

----- Original Message ----- > From: "reed kotler" <rkotler at mips.com> > To: llvmdev at cs.uiuc.edu > Sent: Wednesday, February 13, 2013 6:00:45 PM > Subject: [LLVMdev] changing opcode > > Is there a simple way to just change the opcode of a machine > instruction. > > I have a lot of long/short pairs where when I know the offset, i can > replace

Is there a simple way to just change the opcode of a machine instruction. I have a lot of long/short pairs where when I know the offset, i can replace the long version with the short version. Tia. REed

Looking through the X86 GlobalISEL code for selecting loads and stores, I'm not seeing the creation of the MachineMemOperands I'd expect to see and do see being generated by SelectionDAG.  Is this simply an oversight, or is there some aspect of the new design which pushes us away from MMOs? Various parts of the machine instruction level optimization passes use the existence and

ARM begins by putting constants into a basic block following the last one in the function. In some cases, those constants would be better put in a basic block that is before the beginning of the function. Is it possible to create a basic block that is before the first executable instruction of the function?

Is there any code in test/Codegen/ARM for constant islands testing? I could not find any. TIA. Reed

There are still two more patches to put back for conditional branches but the main part of the constant islands as well as unconditional branches seems to work fine and has all been pushed upstream. The rest should be pushed next week. At least it passes all of test-suite. I'm not ready to turn it on as a default for now because I need to review it a lot and do some more testing and

Dear List, This is Elaine, a postgraduate studying in bird distributions in East Asia. I want to calculate Simpson dissimilarity index, based on a presence/absence matrix of bird species in islands in East Asia. (matrix row: 36 islands/matrix column: species ID) (R package vegan to make NMDS and R package betapart) In most papers using vegan for NMDS and betapart for dissimilarity

Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a register by use

Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this