search for: 128bit

Hello, I'm making a compiler utilizing LLVM. Because I want the compiler to support 128bit floating-point operations, I added the code for 128bit floating-point operations and tested these operations in i686, x86_64, SPARCv8 and SPARCv9 machines. Generated codes by LLVM operated normally when using x86_64, SPARCv8 and SPARCv9 machines, but generated codes in a x86 machine produce wrong r...

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 usin...

I'm getting the following error when trying to SDIV integers greater than 128bit (on an AMD64 target). LegalizeIntegerTypes.cpp:2047: void llvm::DAGTypeLegalizer::ExpandIntRes_SDIV(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported SDIV!"' failed. Stack dump: 0. Running pass 'X86 DAG-&g...

How do I emit 80/128 bit FP constants. There is one ConstantFP::get function which takes a double and another that takes a StringRef. Does the StringRef version somehow do what I want? -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail. -------------- next

On 30/04/13 07:33, edA-qa mort-ora-y wrote: > How do I emit 80/128 bit FP constants. There is one ConstantFP::get > function which takes a double and another that takes a StringRef. Does > the StringRef version somehow do what I want? Use the one that takes an APFloat. Ciao, Duncan.

On 01/05/13 12:21, Duncan Sands wrote: >> How do I emit 80/128 bit FP constants. There is one ConstantFP::get >> function which takes a double and another that takes a StringRef. Does >> the StringRef version somehow do what I want? > Use the one that takes an APFloat. APFloat then offers the float/double/string constructors, and various operations. I'm still not sure on

...I1) - Integer Muti-Cycle(M) - Load(L) - Store(S) - FP/ASIMD 0(F0) - FP/ASIMD 1(F1) So I think `A57UnitW` and `A57UnitX` should be the TableGen records defining pipeline F0 and F1, respectively. So `A57UnitW` and `A57UnitX` together compose a `ProcResGroup`, `A57UnitV`, which can execute a 128bit ASIMD floating point operation, such as FMLA(Q-form), in a single clock cycle. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But in line 479-483 of `AArch64SchedA57.td`, as shown below ``` def A57WriteFPVMAD : SchedWriteRes<[A57UnitV]> { let Latency =...

...of the copying speex performs without calling memcpy. Although memcpy() is generally a pretty nasty function when copying very small blocks of data (< 128 bits) from a performance point of view it does have significant advantages when copying longer runs as some architectures are optimized for 128bit memory access others 64bit access etc, 8 bit stores can actually result in code that's up to 16 times slower (in the case of the 128bit architecture). Thanks, keep up the good work Stewart Miles http://www.mobygames.com/developer/sheet/view/developerId,62864/

Hi all. Solaris 10's default libcrypto does not have support for AES 192 and 256 bit functions. The attached patch, against -current, and based partially on an earlier one by djm, will use OpenSSH's builtin rijndael code for all AES crypto functions and thus will allow it to build and function on Solaris 10 without the extra crypto packages (SUNWcry, SUNWcryr) or a locally built OpenSSL.

...(attached as fc_long.ll) that when run through the optimizer produces 65bit integer math(fc_long-opt.ll). Now I understand that llvm can have any length integer, but I consider turning a 64bit mul into multiple 65 bit instructions to be a 'bad' optimization. This eventually expands to a 128bit multiply call(__multi3) which I have absolutely no interest in supporting. So I'm wondering what optimization might be the culprit here so I can disable it in this situation. Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pip...

2016-01-03 20:11 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > On Sun, Jan 3, 2016 at 1:52 PM, Csányi Pál <csanyipal at gmail.com> wrote: >> So there is an AMD card too: >> VGA ASUS AMD Radeon R7 240, R7240-2GD3-L, 2GB DDR3, 128bit, >> 730/1800MHz, HDMI, DVI-D, D-sub >> >> What would be the best choice here: >> GEFORCE GT 730 >> or >> AMD Radeon R7 240 ? > > I don't want to recommend one or the other, esp as I'm unaware of the > specifics around exact AMD GPU support. But i...

Yes, Another reason this is useful is for register-type specific representations of said register. For example, all my registers are 128bit vector registers, however, if I am only dealing with 32 bit vector registers, I can add write/read masks that tell the underlying hardware not to work on the whole register, but just a subset of the components. 32bit scalar mov: mov r1.x___, r0.x000 64bit scalar mov: mov r1.xy__, r0.xy00 96bit s...

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

On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > To my knowledge, I don't think there is an easy way to get the MVT > information from a MachineOperand. Why do you need it for? In my See the thread I started on this very topic. Spilling is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a >

Hi all, is there any way to compare two 128bit values? I have tried 3 different approaches and they all fail with an internal assertion. I'm running llvm 2.4 on x86 with the following command line: > llvm-as test.ll -o test.bc > llc test.bc -filetype=asm I would expect the code generator to emit a sequence of SSE instructions....

...>> optimizer produces 65bit integer math(fc_long-opt.ll). >> >> >> >> Now I understand that llvm can have any length integer, but I consider >> turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ >> optimization. This eventually expands to a 128bit multiply call(__multi3) >> which I have absolutely no interest in supporting. So I’m wondering what >> optimization might be the culprit here so I can disable it in this >> situation. > > I'm pretty sure this is the fault of one of the loop passes (I forget > which on...

...l types all map to the same register class? Why not specify several classes instead? I have many instructions that work irrespective of the data type. By allowing multiple types to work in a single register class, this reduces the number of times I have to duplicate code. For, example, I have a 128bit copy that works on i32, i64, f32, f64 data along with vector types up to 128bits in length. Tablegen should be smart enough to figure out that if my 128 bit register class has the 32bit and 64 bit register classes as subclasses, then a pattern written for the 128bit register class should also work...

...) that when run through the > optimizer produces 65bit integer math(fc_long-opt.ll). > > > > Now I understand that llvm can have any length integer, but I consider > turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ > optimization. This eventually expands to a 128bit multiply call(__multi3) > which I have absolutely no interest in supporting. So I’m wondering what > optimization might be the culprit here so I can disable it in this > situation. I'm pretty sure this is the fault of one of the loop passes (I forget which one off the top of my head)....

...up. > On another not, is there any known examples of using Tablegen with a > typeless register class? What do you mean? The register types that are generated themselves don't hold any type information. How the bits are treated depends on the instruction being generated. My register are 128bit in width that can hold either 32bit floats and ints, or 64 bit floats in scalar or vector form. All the other Target backends seem to have register classes for each specific use case, not a register class that can handle every case, i.e. if a 256bit register is needed, then I just use 2 sequential...

...ansparency? Talking about CD level audio (16bit; 44,1 kHz; Stereo) The only source I could find regarding that was: http://wiki.hydrogenaud.io/index.php?title=Opus#Music_encoding_quality But that seems to imply that transparency is achieved with 256bit... and "close to transparency" wit 128bit... and then I wonder why one would need Opus, because I thought that's about the same for AAC/MP3/Vorbis. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available Url :...