search for: pjcoup

...39:38 +0000 From: Elena Demikhovsky <elena.demikhovsky at intel.com> Reply-To: reviews+D17497+public+90f3d1b9468ba8ca at reviews.llvm.org To: elena.demikhovsky at intel.com, apilipenko at azulsystems.com, listmail at philipreames.com, ayal.zaks at intel.com, Matthew.Arsenault at amd.com, pjcoup at gmail.com CC: llvm-commits at lists.llvm.org delena created this revision. delena added reviewers: apilipenko, reames, Ayal, arsenm, pjcoup. delena added a subscriber: llvm-commits. delena set the repository for this revision to rL LLVM. This is an alternative proposal for supporting addres...

...<elena.demikhovsky at intel.com> >> Reply-To: reviews+D17497+public+90f3d1b9468ba8ca at reviews.llvm.org >> To: elena.demikhovsky at intel.com, apilipenko at azulsystems.com, >> listmail at philipreames.com, ayal.zaks at intel.com, >> Matthew.Arsenault at amd.com, pjcoup at gmail.com >> CC: llvm-commits at lists.llvm.org >> >> >> >> delena created this revision. >> delena added reviewers: apilipenko, reames, Ayal, arsenm, pjcoup. >> delena added a subscriber: llvm-commits. >> delena set the repository for this revisi...

On Mon, Apr 22, 2013 at 8:09 AM, Pete Couperus <pjcoup at gmail.com> wrote: > Hello Reed, > > Basic blocks need to end with a terminator instruction. > There is an "unreachable" terminator instruction, whose documentation says: > "the presence of this instruction indicates some higher level knowledge > that the end...

...0 > From: Elena Demikhovsky <elena.demikhovsky at intel.com> > Reply-To: reviews+D17497+public+90f3d1b9468ba8ca at reviews.llvm.org > To: elena.demikhovsky at intel.com, apilipenko at azulsystems.com, listmail at philipreames.com, ayal.zaks at intel.com, Matthew.Arsenault at amd.com, pjcoup at gmail.com > CC: llvm-commits at lists.llvm.org > > delena created this revision. > delena added reviewers: apilipenko, reames, Ayal, arsenm, pjcoup. > delena added a subscriber: llvm-commits. > delena set the repository for this revision to rL LLVM. > > This is an alter...

Hello Reed, Basic blocks need to end with a terminator instruction. There is an "unreachable" terminator instruction, whose documentation says: "the presence of this instruction indicates some higher level knowledge that the end of the block cannot be reached." (see include/llvm/IR/Instructions.h). I've been able to suppress the return using this. I'm not completely

On 04/20/2013 02:04 PM, Reed Kotler wrote: > On 04/20/2013 01:30 PM, reed kotler wrote: >> Can I create a "naked" function that has only inline assembler and no >> return IR for example? >> >> If I create just a function will an empty basic block, it's core dumps. >> >> I'm debugging it now. > > Seems that you have to have at least a

...ee the definitions for each intrinsic. Then, the name mapping is just: int_foo_bar -> llvm.foo.bar() int_ prefix becomes llvm., and all underscores turn into periods. Ex: int_nvvm_read_ptx_sreg_tid_x -> llvm.nvvm.read.ptx.sreg.tid.x() On Fri, Mar 1, 2013 at 3:51 PM, Pete Couperus <pjcoup at gmail.com> wrote: > Hi Timothy, > > I'm not sure what you mean by this working for other intrinsics, but > in this case, I think you want the intrinsic name > llvm.nvvm.read.ptx.sreg.tid.x. > > For me, this looks like: > %x = call i32 @llvm.nvvm.read.ptx.sreg.tid....

Hi Timothy, I'm not sure what you mean by this working for other intrinsics, but in this case, I think you want the intrinsic name llvm.nvvm.read.ptx.sreg.tid.x. For me, this looks like: %x = call i32 @llvm.nvvm.read.ptx.sreg.tid.x() Pete On Fri, Mar 1, 2013 at 11:51 AM, Timothy Baldridge <tbaldridge at gmail.com> wrote: > I'm building this with llvm-c, and accessing these

I'm building this with llvm-c, and accessing these intrinsics via calling the intrinsic as if it were a function. class F_SREG<string OpStr, NVPTXRegClass regclassOut, Intrinsic IntOp> : NVPTXInst<(outs regclassOut:$dst), (ins), OpStr, [(set regclassOut:$dst, (IntOp))]>; def INT_PTX_SREG_TID_X : F_SREG<"mov.u32 \t$dst, %tid.x;",

Hi Reed, Sorry about the off-list reply. I need to reset my list preferences. If I build: cmp.c: int cmp_single(float a) { return (a != a) ? 1 : 0; } int cmp_double(double a) { return (a != a) ? 1 : 0; } with clang -target mips-unknown -S cmp.c I get calls to __unordsf2 and __unorddf2. Pete

Hello, This is an interesting example. Whenever I see strange things like this, I use opt's -lint. In this case, opt -lint reports: Undefined behavior: Call return type mismatches callee return type %call = call float @alias_f32(float %tmp2) #1 You'll get a similar report when the parameter types mismatch. Pete On Wed, May 29, 2013 at 5:40 PM, Arsenault, Matthew <