similar to: Larger than 64bit fixed instruction encoding

Hello, I read the suggestion posted on this list about adding -D_LARGEFILE64_SOURCE to build rsync, but it does not work correctly on my platform which is an: 9000/800/N4000-55 with 64bit hp-ux using HP's C compiler (B3901BA) i solved the problem by building rsync as a 64 bit application: CFLAGS='+O3 +DD64' ./configure --prefix=/opt/rsync could you please add this flag to configure if

>> Can I tell tablegen to have two encodings and switch between them >> using a predicate? After some deliberations, I modified tablegen to generate several versions of the GenCodeEmitter file. My tablegen now accepts a new command line parameter called "emitter-instfld". This specifies the name of the field in Instruction that holds the encoded bytes. In my target's td

Hi, The ISA I am working on is always encoded in 128bit binary format. I find that getBinaryCodeForInst() only return at most 64bit Encoding. So, I think the proper way to encode the instructions is to write the XXXMCCodeEmitter by myself instead of automatic generation. right? Is there any guideline/suggestion on how to write the XXXMCCodeEmitter using current LLVM infrastructure? I want to use

Hello, I have a compiler in LLVM 2.9 for the KCPM3 processor. I'd like to create a subtarget for the new cpu version called KCPSM6. Besides a couple of new instructions which are not important at the moment, the KCPSM6 cpu has different instruction opcodes. Semantically the instructions are the same, hence I'd like to keep all the lowering and pattern matching stuff unmodified For

Hi, I'm investigating the size of Clang's generated binaries relative to GCC, when targeting Android, and I've noticed that Clang's exception tables are much larger -- the .ARM.extab section is about 2.5 times as large in two examples. I noticed a couple of differences between Clang and GCC: 1. *ULEB128 encoding.* In the call site table, GCC encodes offsets using a ULEB128

Dear R-Core team, Dear Rcpp team and other package teams, Dear R users, The new package 'bit64' is available on CRAN for beta-testing and code-reviewing. Package 'bit64' provides fast serializable S3 atomic 64bit (signed) integers that can be used in vectors, matrices, arrays and data.frames. Methods are available for coercion from and to logicals, integers, doubles,

Dear R-Core team, Dear Rcpp team and other package teams, Dear R users, The new package 'bit64' is available on CRAN for beta-testing and code-reviewing. Package 'bit64' provides fast serializable S3 atomic 64bit (signed) integers that can be used in vectors, matrices, arrays and data.frames. Methods are available for coercion from and to logicals, integers, doubles,

I am working on an LLVM backend for the AVR architecture, and am having troubles working with the codegen layer, trying to get around the quirks of the binary encodings of the AVR ISR. There are several different families of AVR microcontrollers, each with a minimum 'core' instruction set. Each family builds upon (or removes) the core ISR with more instructions or different encodings. My

On Thu, Mar 01, 2012 at 06:16:46PM +0000, Demikhovsky, Elena wrote: > vmovaps should not access stack if it is not aligned to 32 I'm not completely sure I understand your problem. Are you saying that the generated code assumes 256bit alignment, your default stack alignment is 128bit and LLVM doesn't adjust it automatically? Joerg

Thanks for all the the info! I'm still in the process of narrowing down the performance difference in my code. I'm no longer convinced its related to only the unaligned loads/stores alone since extracting this part of the kernel makes the performance difference disappear. I will try to narrow down what is going on and if it seems related LLVM, I will post an example. Thanks again, Zach

Hi all, I have error installing character-encoding gem on ubuntu 11.10 64bit. The error details are in following link http://pastie.org/2768063 -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to

On Tue, 30 May 2017, Nemanja Ivanovic wrote: > This is typically accomplished with something like PPC's `RegConstraint` and > `NoEncode`. You can see examples of it that are very similar to what you're after in > PPC's load/store with update forms (i.e. load a value and update the base register > with the effective address - these are used for pre-increment loads/stores).

Hi, Yes. On Sandybridge 256-bit loads/stores are double pumped. This means that they go in one after the other in two cycles. On Haswell the memory ports are wide enough to allow a 256bit memory operation in one cycle. So, on Sandybridge we split unaligned memory operations into two 128bit parts to allow them to execute in two separate ports. This is also what GCC and ICC do. It is very

Hello, I forgot in my last reply that my DWT implementation can be speed up, for example I'm doing for now: for (;_X1<_E_;_X1++,_RES+=2) //dilatation { _RES[0]=_X1[0]<<3; _RES[1]=(_X1[1]+_X1[0])<<2; } then for (;_X2<_E_;_X2++,_RES+=2) //details { _RES[0]-=(_X2[1]+_X2[0])<<1; _RES[1]+=6*_X2[1]-_X2[2]-_X2[0];

Hello, I am in the process of troubleshooting another problem and noticed a rather strange behavior with the openssh client. A client (OpenSSH 5.3) and a server (6.7p1) do the TCP handshake, the client announces a MSS of 1460 (its MTU is 1500), while the server announces a MSS of 1260 (its MTU is set to 1300). What troubles me is, that the client is sending the server a frame of 2034 bytes

When stack is unaligned, LLVM should generate vmovups instead of vmovaps. - Elena -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Joerg Sonnenberger Sent: Thursday, March 01, 2012 20:31 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack alignment on X86 AVX seems incorrect On Thu, Mar 01, 2012 at 06:16:46PM +0000,

On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > I'm starting to look into binary instruction encodings in TableGen, and I'm > a bit confused on how the instruction fields are populated. Perhaps I'm > just being dense, but I cannot see how SDAG operands are translated into > the encoding fields. Can someone please explain the following snippet from

Nadav, We see multiple regressions after r172868 in ISPC compiler (based on LLVM optimizer). The regressions are due to spill/reloads, which are due to increase register pressure. This matches Zach's analysis. We've filed bug 17285 for this problem. Is there any possibility to avoid splitting in case of multiple loads going together? Dmitry. On Wed, Jul 10, 2013 at 1:12 PM, Zach

I'm starting to look into binary instruction encodings in TableGen, and I'm a bit confused on how the instruction fields are populated. Perhaps I'm just being dense, but I cannot see how SDAG operands are translated into the encoding fields. Can someone please explain the following snippet from the PPC back-end. The AND instruction in PPC is defined as: 1011 def AND :

On Jul 24, 2012, at 3:52 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > > I'm starting to look into binary instruction encodings in TableGen, and I'm > > a bit confused on how the instruction