search for: 256bit

...s scalar > cost. > > > > > I am suspecting this is something specific to architecture difference > between AVX and AVX2. I am naive to architecture specifics in this case. > > I assume that this is integer ADD, because AVX1 only supported floating > point arithmetic on 256bit vectors, while AVX2 added support for 256bit > integer arithmetic. So, it makes sense that the cost that AVX1 gives this > operation is much higher. > > > > > > I would be glad if someone clarifies on this. > > > > Thanks. > > > > Regards, > > S...

Hi all, I have a query regarding Cost Table for AVX2 in TargetTransformInfo. The table consist of entries for shift and div operations only. There are no entries for ADD, SUB and MUL for AVX2 cost table. Those entries are present in Cost Table for AVX. The reason for query is - when my sub target feature is AVX2, in SLP Vectorization, while calculating scalar cost of ADD, it doesn't see

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

...ncluding classical music) to achieve more or less transparency? 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-...

Is there anyway in C I can write a function which accepts a very large integer? That is, say in LLVM I'm using a 256bit integer, is it possible to write a C function which accepts that value? I understand it wouldn't be standard C, or may not even be pretty, but that doesn't matter. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign you...

...bject: Re: [LLVMdev] Stack alignment on X86 AVX seems incorrect 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 _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev --------------...

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 possible that the decision to split the wide vectors causes a regression. If the memory ports...

Frank, It sounds like the SLP vectorizer thinks that it is more profitable to use 128bit wide operations (because 256bit operations are double pumped on Sandybridge). Did you see a different result on Haswell? Thanks, Nadav > On Jul 1, 2015, at 11:06 AM, Frank Winter <fwinter at jlab.org> wrote: > > I realized that the function parameters had no alignment attributes on them. However, even adding...

..., 2013 at 10:15 PM, Nadav Rotem <nrotem at apple.com> wrote: > >> 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 possible that the decision to split the wide vector...

...in, Zach On Tue, Jul 9, 2013 at 10:15 PM, Nadav Rotem <nrotem at apple.com> wrote: > 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 possible that the decision to split the wide vectors causes a > regr...

...v Rotem <nrotem at apple.com> wrote: >> >>> 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 possible that the decision to s...

...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 128bit registers. Also, my instruction set has basically unlimited registers, I can't really seem a way to model this either. > Or with instruction formats where the modifiers are > on the registers and the instructions(i.e. mul_x2 GPR0, G...

./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 vmovaps -208(%rbp), %ymm9 vmovaps -272(%rbp), %ymm7 vmovaps -304(%rbp), %ymm0 vmovaps -112(%rbp), %ymm0 vmovaps -80(%rbp), %ymm1 vmovaps -112(%rbp), %ymm0

...lignment on X86 AVX seems incorrect > > 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 > Hey Joerg, The faulty code can be found in function X86InstrInfo::storeRegToStackSlot(...) from /lib/Target/X86/X86InstrInfo.cpp. > bool isAligned = (RI.getStackAlignment(...

edA-qa mort-ora-y <eda-qa at disemia.com> writes: > Is there anyway in C I can write a function which accepts a very large > integer? That is, say in LLVM I'm using a 256bit integer, is it possible > to write a C function which accepts that value? > > I understand it wouldn't be standard C, or may not even be pretty, but > that doesn't matter. What's wrong with passing the address of the integer?

Hi, for those who have adopted ECDSA, Are there still any commonly used IMAPS/POP3S clients that still can not handle ECDSA certificates? I know you can set up Dovecot dor dual cert, I am just trying to determine if there still is a real world need to.

hello, I want to lunch Battlefield Bad Company 2 on my Ubuntu 10.10 with Wine 1.3.10. I have allready installed DirectX 9.0c using winetricks. But I cant lunch it :( Here is a log from terminal: fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_HANDLE_INFORMATION fixme:ntdll:NtQueryObject Unsupported information class 3 err:rpc:I_RpcGetBuffer no binding fixme:ntdll:NtQueryInformationProcess

...xed length instruction encodings. It can only handle up to 64bit fixed length instruction encodings. I'm wondering if anyone has spent time investigating lifting this limitation and what all problems it would hit with various bits of LLVM assuming the max size is 64bit. In particular 128bit and 256bit fixed length instruction encodings are of interest to me which I can work around with going down the x86 path and lying to LLVM that it has variable instruction encoding. Any thoughts or ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...

...achieve more or less transparency? > 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. > _______________________________________________ > opus mailing list > opus a...

...chieve more or less transparency? > 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. > > > > _______________________________________________ > opus mail...