search for: _array

...gnostic diag; Module *M = parseIRFile(InputIR, diag, context).get(); if (M == nullptr) { diag.print("LLVM", errs()); exit(-1); } assert(M->isMaterialized() && "Module not materialized!"); PointerType *ArrayPtrTy = M->getTypeByName("struct._Array")->getPointerTo(); ``` However this piece of code crashes at Module::getTypeByName because getContext().pImpl is NULL pointer. Other similar issues include Module::getTypeByName results in a NULL pointer dereference because TheTable in StringMap is not allocated/initialized. It would be...

...= 0; i < 1000; ++i) > Array[i] += X; > } > > Compile with -O3 on OS/X gave me this: > > _test: > mflr r5 > bcl 20,31,"L00000000001$pb" > "L00000000001$pb": > mflr r2 > mtlr r5 > addis r4,r2,ha16(L_Array$non_lazy_ptr-"L00000000001$pb") > li r2,0 > lwz r9,lo16(L_Array$non_lazy_ptr-"L00000000001$pb")(r4) > li r4,1000 > mtctr r4 > L9: > lwzx r7,r2,r9 ; load > add r6,r7,r3 ; add > stwx...

...scripts specifies which sections should be kept in the final output even if GC judges that it could be discarded. Perhaps, at this moment, it would suffice to provide an option to specify which sections must be kept. Additionally, perhaps the ELF reader or writer could always keep the .init{.*,_array}, .fini{.*,_array} and preinit_array sections. -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 10/01/12 21:06, Sid Manning wrote: > > I committed a patch to update the ReaderELF.cpp that, i...

...r | grep 9 > +; change preceeding line form ... | grep 8 to ..| grep 9 since > +; with new fastcc has std call semantics causing a stack adjustment > +; after the function call > > Not sure if I understand this. Can you illustrate with an example? Sure The code generated used to be _array: subl $12, %esp movss LCPI1_0, %xmm0 mulss 16(%esp), %xmm0 movss %xmm0, (%esp) call L_qux$stub mulss LCPI1_0, %xmm0 addl $12, %esp ret FastCC use to be caller pops arguments so there was no stack adjustment...

...ne form ... | grep 8 to ..| grep 9 since >> +; with new fastcc has std call semantics causing a stack adjustment >> +; after the function call >> >> Not sure if I understand this. Can you illustrate with an example? > > Sure > > The code generated used to be > _array: > subl $12, %esp > movss LCPI1_0, %xmm0 > mulss 16(%esp), %xmm0 > movss %xmm0, (%esp) > call L_qux$stub > mulss LCPI1_0, %xmm0 > addl $12, %esp > ret > > FastCC use to be caller pops argu...

On Tue, 4 May 2004, Patrick Flanagan wrote: > I was able to run through all the C/C++ benchmarks in SPEC using LLVM. > I'm on OS X 10.3.3. I did a quick comparison between LLVM (latest from > CVS as of 4/27) and gcc 3.3 (Apple's build 20030304). For simplicity's > sake, the only flag I used was -O3 for each compiler and I was using > the C backend to generate native

> > FastCC use to be caller pops arguments so there was no stack > > adjustment after the > > call to qux. Now FastCC has callee pops arguments on return semantics > > so the > > x86 backend inserts a stack adjustment after the call. > > > > _array: > > subl $12, %esp > > movss LCPI1_0, %xmm0 > > mulss 16(%esp), %xmm0 > > movss %xmm0, (%esp) > > call L_qux$stub > > subl $4, %esp << stack adjustment because qux pops > > arguments on r...

I was able to run through all the C/C++ benchmarks in SPEC using LLVM. I'm on OS X 10.3.3. I did a quick comparison between LLVM (latest from CVS as of 4/27) and gcc 3.3 (Apple's build 20030304). For simplicity's sake, the only flag I used was -O3 for each compiler and I was using the C backend to generate native code for PPC. Most of the LLVM results were close to gcc

Hi Arnold, This is a very good first step! Thanks! Comments below. Evan Index: test/CodeGen/X86/constant-pool-remat-0.ll =================================================================== --- test/CodeGen/X86/constant-pool-remat-0.ll (revision 42247) +++ test/CodeGen/X86/constant-pool-remat-0.ll (working copy) @@ -1,8 +1,10 @@ ; RUN: llvm-as < %s | llc -march=x86-64 | grep LCPI | count 3 ;

The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>

...include: update nf_tables.h. bitwise: add support for passing mask and xor via registers. Pablo Neira Ayuso (12): include: typo in object.h C++ wrapper udata: add NFTNL_UDATA_SET_*TYPEOF* definitions udata: support for TLV attribute nesting src: add nftnl_*_{get,set}_array() chain: add NFTNL_CHAIN_FLAGS set_elem: missing set and build for NFTNL_SET_ELEM_EXPR set: support for NFTNL_SET_EXPR expr: masq: revisit _snprintf() expr: nat: snprint flags in hexadecimal Revert "bitwise: add support for passing mask and xor via registers...

...on: int Array[1000]; void test(int X) { int i; for (i = 0; i < 1000; ++i) Array[i] += X; } Compile with -O3 on OS/X gave me this: _test: mflr r5 bcl 20,31,"L00000000001$pb" "L00000000001$pb": mflr r2 mtlr r5 addis r4,r2,ha16(L_Array$non_lazy_ptr-"L00000000001$pb") li r2,0 lwz r9,lo16(L_Array$non_lazy_ptr-"L00000000001$pb")(r4) li r4,1000 mtctr r4 L9: lwzx r7,r2,r9 ; load add r6,r7,r3 ; add stwx r6,r2,r9 ; store addi...

...use to be caller pops arguments so there was no stack >>> adjustment after the >>> call to qux. Now FastCC has callee pops arguments on return >>> semantics >>> so the >>> x86 backend inserts a stack adjustment after the call. >>> >>> _array: >>> subl $12, %esp >>> movss LCPI1_0, %xmm0 >>> mulss 16(%esp), %xmm0 >>> movss %xmm0, (%esp) >>> call L_qux$stub >>> subl $4, %esp << stack adjustment because qux pops >&g...

Hi, All. Does anybody know about ConstantExpr in llvm? What's it? Since it always appears after llvm optimization such as -O2 level, what is it supposed to be to codegen? I am wondering it represents constant value which can be determined or computed at compile-time(actually is link-time) to improve performance. Although we do not know the actual constant value util the object file is linked.

...ch would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at offset 0xd28 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 000200000101 R_AARCH64_ABS64 0000000000000000 .text + d4 The resulting dynamic relocation on the shared object should be: Relocation section '.rela.dyn'...

...gmail.com Hardware: All Status: NEW Version: git Component: Drivers/DRI/nouveau Product: Mesa Created attachment 70747 --> https://bugs.freedesktop.org/attachment.cgi?id=70747&action=edit Patch to fix it Unhandled case PIPE_CAP_CUBE_MAP_ARRAY in nv??_screen.c -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20121128/e1e0b495/attachment.html>

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments