similar to: [LLVMdev] MC backend codegen tutorial

That doesn't actually give you a guarantee that they won't be split up. Phases other than the scheduler may insert instructions in the middle of block (constant island pass, for example). Pseudo-instructions are the canonical answer to that problem. --Owen On Sep 17, 2013, at 11:09 PM, Micah Villmow <micah.villmow at smachines.com> wrote: > I used the A9 schedule as an

On Fri, Jan 13, 2012 at 10:31 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Also, this can be easily reproduced with the following command: > > valgrind --tool=memcheck --show-reachable=yes --leak-check=full > --track-origins=yes --leak-check=full opt -disable-opt -O0 <some random > bitcode file> > > > > Micah > Hi Micah, the

I used the A9 schedule as an example: http://llvm.org/svn/llvm-project/llvm/trunk/lib/Target/ARM/ARMScheduleA9.td The documentation could use more clarity, but this is how I was able to do it to always get two specific instructions to be scheduled together. ________________________________________ From: reed kotler [rkotler at mips.com] Sent: Tuesday, September 17, 2013 8:54 PM To: Micah Villmow

Doh! hit send too soon, patch attached. > -----Original Message----- > From: Villmow, Micah > Sent: Thursday, September 06, 2012 9:17 AM > To: 'Eli Friedman' > Cc: LLVM Developers Mail > Subject: RE: [LLVMdev] FW: RFC: Supporting different sized address space > arithmetic > > Eli, > Here is the first of many patches that adds support for specifying >

On 09/17/2013 04:51 PM, Micah Villmow wrote: > Reed, > Couldn't you also use instruction scheduling classes and specify that the second instruction has a bypass from the first instruction? The scheduler should always schedule them together in that case. > > Micah > I'm not sure exactly what you mean. Can you point me to an example of that? TIA. Reed >>

> -----Original Message----- > From: Villmow, Micah > Sent: Friday, August 24, 2012 2:56 PM > To: 'Eli Friedman' > Cc: LLVM Developers Mailing List > Subject: RE: [LLVMdev] RFC: Supporting different sized address space > arithmetic > > Eli, > There is a patch that implements the beginning what I think is the > correct approach to support the backend

We no longer have vsetcc, so the comment is wrong. The code looks incorrect. The fact that a vector is power-of-two does not guarantee anything about its legality. For example <128 x i64> would pass the condition in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Friday, July 27, 2012 22:33 To: Rotem, Nadav; Developers Mailing List

My implementation of predicated instructions is similar to ARM backend. I traced ARM and PowerPC backend for reference. If, David, you were saying a implementation of predication in LLVM IR, I didn't do that. It was partly because I was not (and is still not) very familiar with LLVM's design; so I didn't know how to do that. I agree what Micah said; LLVM's code generator has a

On Mon, 27 Aug 2012 15:25:50 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Most likely this code was added before getSExtOrTruncate was added, > but not 100% sure. It seems to assume that no pointer can be more > than 64bits in size. Does LLVM generally support pointers of greater than 64 bits? -Hal > > > -----Original Message----- > >

> -----Original Message----- > From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On Behalf > Of James Molloy > Sent: Wednesday, September 12, 2012 12:18 PM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu; Villmow, Micah > Subject: Re: [cfe-dev] [LLVMdev] SPIR provisional specification is now > available in the Khronos website >

if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't

Micah, There are a number of variable names in this patch that don't follow the naming convention (which specifies that they should start with an uppercase letter). > if (PtrBits < 64) > - OffsVal = DAG.getNode(ISD::TRUNCATE, getCurDebugLoc(), > - TLI.getPointerTy(), > + OffsVal = DAG.getNode(ISD::TRUNCATE,

Most likely this code was added before getSExtOrTruncate was added, but not 100% sure. It seems to assume that no pointer can be more than 64bits in size. > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Friday, August 24, 2012 4:27 PM > To: Villmow, Micah > Cc: LLVM Developers Mail > Subject: Re: [LLVMdev] FW: RFC: Supporting different sized

Hi Boaz, David, Thanks for taking my responses on board. > 1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels. Can we agree on this item? Hmm, this is the one I was most shaky on. I still don't fully understand

unsubscribe ----- Original Message ----- From: llvmdev-request at cs.uiuc.edu To: llvmdev at cs.uiuc.edu Sent: Tuesday, November 19, 2013 5:08:13 PM Subject: LLVMdev Digest, Vol 113, Issue 74 Send LLVMdev mailing list submissions to llvmdev at cs.uiuc.edu To subscribe or unsubscribe via the World Wide Web, visit http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev or, via email, send a message

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of David A. Greene > Sent: Tuesday, August 10, 2010 12:02 PM > To: Che-Liang Chiou > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Upstream PTX backend that uses target > independent code generator if possible > > Che-Liang Chiou <clchiou

Reed, Couldn't you also use instruction scheduling classes and specify that the second instruction has a bypass from the first instruction? The scheduler should always schedule them together in that case. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of reed kotler > Sent: Tuesday, September 17, 2013

Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From:

Hi, Chris Lattner wrote: > On Aug 10, 2010, at 12:05 PM, David A. Greene wrote: > > >>> The PTXBackend probably needs more test cases. I'm currently covering a >>> lot of LLVM and PTX features but the test suite is still not exhaustive. >>> I took the coding standards into account and the license is now >>> compatible to LLVM. I don't

(Sorry about the wall of text, it ended up as a brain dump of a bunch of backend-related documentation that I know about/have bookmarked in the past. Hopefully there's something useful in there.) If you haven't stumbled across them already, these might be helpful: http://llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf http://jonathan2251.github.io/lbd/