search for: iptr

...n problem.) > > With this explanation, the idea of adding a union type seems a lot more > compelling to me. For the record, I'm not opposed to an intptr_t type or a > union type, but the semantics have to be clean and well specified. > > -Chris Well, as far as intp goes (or iptr if you prefer - the naming convention in LLVM is i<size>), here's what I would expect: - General rule #1: If an instruction accepts both i32 and i64, then it should accept iptr as well. If it only accepts i32, then it can continue to only accept i32. - General rule #2: It sho...

On Nov 10, 2009, at 4:10 PM, Talin wrote: > I realize that most users of LLVM aren't affected by this, because most frontends aren't target-neutral, and thus know in advance how big a pointer is. At least, that's my impression. I believe that. > There's only a tiny handful of fairly esoteric cases which require selecting a target before you generate IR. Unfortunately, the

...that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat pre_store" get matched with those of memri. It is defined with operand types as: let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); while Pat is defined as: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; So now how iPTR:$ptrreg and iaddroff:$ptroff get matched with ptr_rc_nor0:$reg and dispRI:$imm respectively? I mean the types are not exactly matching. Probably something is amiss in my understanding. -Anitha &...

...esample.c index 7b5a308..8131380 100644 --- a/libspeex/resample.c +++ b/libspeex/resample.c @@ -361,7 +361,7 @@ static int resampler_basic_direct_single(SpeexResamplerState *st, spx_uint32_t c sum = accum[0] + accum[1] + accum[2] + accum[3]; */ #else - sum = inner_product_single(sinc, iptr, N); + inner_product_single(&sum, sinc, iptr, N); #endif out[out_stride * out_sample++] = SATURATE32(PSHR32(sum, 15), 32767); @@ -412,7 +412,7 @@ static int resampler_basic_direct_double(SpeexResamplerState *st, spx_uint32_t c } sum = accum[0] + accum[1] + accum[2]...

On Nov 12, 2009, at 11:29 AM, Talin wrote: > > Well, as far as intp goes (or iptr if you prefer - the naming > convention in LLVM is i<size>) How about "intptr". > here's what I would expect: > General rule #1: If an instruction accepts both i32 and i64, then it > should accept iptr as well. If it only accepts i32, then it can > continu...

2013/6/23 David Chisnall <David.Chisnall at cl.cam.ac.uk> > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we > have an iPTR256 for our fat pointers. This causes some problems with > constraints, because the way that TableGen resolves constraints is not > expected to handle multiple pointer types. We've added a flag that can be > set on a per-backend basis to turn this off....

Hi Duncan, I've modified my backend such that the function isn't called anymore with iPTR. I still think that if iPTR is an invalid input to getValueTypeList() that the function should have at least an assert checking that. Thanks, Javier Hi Javier, > I've observed in some tests that getValueTypeList() is sometimes called > with type MVT::iPTR. I think this is a bug...

Hi, How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of stwu should get matched with the given pre_store. But I am confused as to how "ptroff" and "ptrreg" get matched with "memri" used in...

David, thanks for your immediate response. Since iPTR is a reserved type for tablegen internal use, can you make a further explanation? On the other hand, it can be simply treated as a register class assignment problem during register allocation. Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs...

Hi, In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off. Our problem is pe...

Hello, I've observed in some tests that getValueTypeList() is sometimes called with type MVT::iPTR. There is a discrepancy between the size of the array VTs and the use in getTypeValueList(). The array is allocated with space for elements up to LAST_VALUE_TYPE and iPTR is defined after it. The enumerator value of iPTR is between LAST_VALUE_TYPE and LastSimpleValueType. For this reason the check...

...h base, length, permissions, enforced in hardware). We had to fix a few things where LLVM assumes that pointers are integers, but the different size pointers in different address spaces part works very well. The biggest weakness is in TableGen / SelectionDAG, where you can't write patterns on iPTR that depend on a specific AS (actually, you can't really write patterns on iPTR at all, as LLVM tries to lower iPTR to some integer type first, even when this doesn't make any sense [e.g. on an architecture with separate address and integer registers]). Having AS0 be a byte pointer, which...

...tMergeInputChains1_0, > /*2254*/ OPC_EmitInteger, MVT::i64, 0, > /*2257*/ OPC_MorphNodeTo, TARGET_VAL(XSTG::LOADI64_RI), > 0|OPFL_Chain|OPFL_MemRefs, > 1/*#VTs*/, MVT::i64, 2/*#Ops*/, 1, 2, > // Src: (ld:i64 (XSTGADDR_NORMAL:iPTR > (tglobaladdr:iPTR):$addr))<<P:Predicate_unindexedload>><<P:Predicate_load>> > - Complexity = 10 > // Dst: (LOADI64_RI:i64 (tglobaladdr:i64):$addr, 0:i64) > > Not sure why the initial Opcode index is being set to 0 instead of 2235? That...

...;Pat" operands get matched? I am trying to follow the example > given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process > > In the latest trunk of ppcintrinfo.td <http://ppcintrinfo.td> > following pattern is defined: > > def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), > (STWU $rS, iaddroff:$ptroff, $ptrreg)>; > > I understand that input operand list i.e. ins of stwu should get > matched with the given pre_store. But I am confused as to how > "ptroff" and "ptrreg" get matched with...

...s/comments/suggestions? I've been poking at this a bit more, and have tried wrapping the ptr_rc within a larger blob; I'm getting different error messages out, but can't tell whether or not this is progress. Using the memri definitions as inspiration: +def ptr_rc_wrapper : Operand<iPTR> { + let PrintMethod = "printMemRegImm"; + let MIOperandInfo = (ops ptr_rc:$ea_result); +} And then swapping out the ptr_rc: references like so: -def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc:$ea_result), (ins memri: $addr), +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrap...

...r recognizing that variable argument intrinsic and I have no idea how it's done. Right now I'm trying following: def CustomOpParams : SDTypeProfile<0,2,[]>; def customop : SDNode<"ISD::INTRINSIC_VOID", CustomOpParams>; def : Pat<(customop tglobaladdr:$dst,iPTR:$vararg), (int_tce_customop tglobaladdr:$dst, iAny:$vararg)>; def : Pat<(call texternalsym:$dst,iAny:$vararg), (int_tce_customop texternalsym:$dst, iAny:$vararg)>; but compilation gives following error: isVoid:void anonymous.52: (intrinsic_void:void 197:iPTR,...

Hi all, I've been poking at AsmParser support for powerpc64 (ppc64-elf-linux-abi) and have run into some behavior I don't understand with the ptr_rc references coming out of the PPC*.td files when generating the asm-matcher files. For instance : $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ -gen-asm-matcher

...px_word16_t *ptr; - /* Do the memory part */ - for (j=0;last_sample-N+1+j < 0;j++) - { - sum += MULT16_16(mem[last_sample+j],st->sinc_table[samp_frac_num*st->filt_len+j]); + const spx_word16_t *sinc = & sinc_table[samp_frac_num*N]; + const spx_word16_t *iptr = & in[last_sample]; + +#ifndef OVERRIDE_INNER_PRODUCT_SINGLE + float accum[4] = {0,0,0,0}; + + for(j=0;j<N;j+=4) { + accum[0] += sinc[j]*iptr[j]; + accum[1] += sinc[j+1]*iptr[j+1]; + accum[2] += sinc[j+2]*iptr[j+2]; + accum[3] += sinc[j+3]*iptr[j+3];...

...px_word16_t *ptr; - /* Do the memory part */ - for (j=0;last_sample-N+1+j < 0;j++) - { - sum += MULT16_16(mem[last_sample+j],st->sinc_table[samp_frac_num*st->filt_len+j]); + const spx_word16_t *sinc = & sinc_table[samp_frac_num*N]; + const spx_word16_t *iptr = & in[last_sample]; + +#ifndef OVERRIDE_INNER_PRODUCT_SINGLE + float accum[4] = {0,0,0,0}; + + for(j=0;j<N;j+=4) { + accum[0] += sinc[j]*iptr[j]; + accum[1] += sinc[j+1]*iptr[j+1]; + accum[2] += sinc[j+2]*iptr[j+2]; + accum[3] += sinc[j+3]*iptr[j+3];...

On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 12, 2009, at 11:29 AM, Talin wrote: > > > Well, as far as intp goes (or iptr if you prefer - the naming convention in > LLVM is i<size>) > > > How about "intptr". > > here's what I would expect: > > - General rule #1: If an instruction accepts both i32 and i64, then it > should accept iptr as well. If it only accepts i32,...