search for: 128b

...alled ndiswrapper v 1.52 I installed the driver http://ftp.us.dell.com/network/R164255.EXE The wireless-tools is v 28.2 When I trying to connect to my wireless access point with encryption key disabled everything work fine !!!! When I enabled the encryption key on my wireless access point with ? 128b WEP it's impossible to connect to it. If I need to connect to the same wifi access with an ancryption key (WEP 128b) it's impossible :-( I receved the message that the laptop cannot get an IP Adress. The same laptop under Windows can connect to the same wireless acces point with encrypti...

..._A_iSLo 1056964608; FPUaOffsetClass:%vreg5 96B %vreg6<def> = FMUL_A_oo %vreg0, %vreg5, %RFLAGA<imp-def,dead>; FPUaROUTMULRegisterClass:%vreg6 FPUaOffsetClass:%vreg0,%vreg5 112B %vreg7<def> = COPY %vreg6; FPUaOffsetClass:%vreg7 FPUaROUTMULRegisterClass:%vreg6 128B %vreg8<def> = FADD_A_oo %vreg4, %vreg7, %RFLAGA<imp-def,dead>; FPUaROUTADDRegisterClass:%vreg8 FPUaOffsetClass:%vreg4,%vreg7 144B %FA_ROFF0<def> = COPY %vreg8; FPUaROUTADDRegisterClass:%vreg8 176B MOVSUTO_SU_os_rpc %SU_ROFF0<kill>, %RPC<im...

Hello, Could someone please explain the semantics of TargetOpcode::KILL? Specifically, in this example, which register is killed? Would it be legal for operands 0 and 1 to refer to different registers? 128B %R3<def> = KILL %R3, %R3_1<imp-use>, %R3_23<imp-use> (In my out-of-tree target, %R3 is a <4xi32> register, %R3_1 is an i32 sub-register of %R3, and %R3_23 is a <2xi32> sub-register of %R3). Thanks, Nick -------------- next part -------------- An HTML attachme...

...ns in an AVX context, or else we'll pay the context switch penalty. It might be too big an assumption to assume that movaps and vmovaps have the same timings. Same for movsd. Also, I'm sure you are aware that the Sandybridge optimization guide suggests that unaligned stores be split into a 128b store and 128b extract. This does argue against my above assumption. For full disclosure, I have not timed the individual instructions; just kernels. So, my performance gains may be coming from another source related to this change. Most likely, my gains are from better use of cache, since we woul...

...all, > > > > I've started looking at the GlobalMerge pass, enabled by default on > > ARM and AArch64. I think we should reconsider that, at least for > > AArch64. > > > > As is, the pass just merges all globals together, in groups of 4KB > > (AArch64, 128B on ARM). > > > > At the time it was enabled, the general thinking was "it's almost > > free, it doesn't affect performance much, we might as well use it". > > Now, it's preventing some link-time optimizations (as acknowledged in > > one of the FIX...

Hello, I am currently using MusicOnHold(mpg123), and it works just fine, but every once in a while I will get a flurry of warnings in the CLI like those below and Asterisk will freeze completely, and the only way to come out of it is with a kill -9 . Is mpg123 causing my problem? Is there a specific format of MP3 that should be used/avoided to not have errors like these? Any help would be greatly

...d Predecessors according to CFG: BB#0 BB#1 80B %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 96B %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg10,%vreg9 112B %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 128B %vreg6<def> = CMPEQri %vreg10, 0; PredRegs:%vreg6 IntRegs:%vreg10 176B JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 192B JMP <BB#2> Successors according to CFG: BB#2 BB#1 208B BB#2: derived from LLVM BB %for.end Predecessors...

Just looked up the numbers from Agner Fog for Sandy Bridge for vmovaps/etc for loading/storing from memory. vmovaps - load takes 1 load mu op, 3 latency, with a reciprocal throughput of 0.5. vmovaps - store takes 1 store mu op, 1 load mu op for address calculation, 3 latency, with a reciprocal throughput of 1. He does not list vmovsd, but movsd has the same stats as vmovaps, so I feel it is a

...his identity copy in %bb.1, which is removed. When the copy is erased and the interval is updated (https://github.com/llvm/llvm-project/blob/523cc097fdafa1bb60373dcc70df7dfd31551f56/llvm/lib/CodeGen/RegisterCoalescer.cpp#L1871), the new live interval looks like this: %0 [16r,32B:2)[32B,96r:0)[96r,128B:1) 0 at 32B-phi 1 at 96r 2 at 16r L0000000000000003 [32B,80B:0) 0 at 32B-phi // sub0 This remaining [32B,80B:0) across %bb.1 is a fake phi-only segment. If I freshly recompute LiveIntervals, the subrange is empty as it should be. The verifier doesn't care about this, however it does end up...

...cording to CFG: BB#0 BB#1 > 80B %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 > 96B %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] > IntRegs:%vreg10,%vreg9 > 112B %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 > 128B %vreg6<def> = CMPEQri %vreg10, 0; PredRegs:%vreg6 IntRegs:%vreg10 > 176B JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 > 192B JMP <BB#2> > Successors according to CFG: BB#2 BB#1 > > 208B BB#2: derived from LLVM BB %for....

...location in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big. This means the maximum amount of memory allocated for FDB entries is 2^31 * 128B = 256GiB, which is too much for most computers. Mitigate this by adding a bridge netlink setting IFLA_BR_FDB_MAX_ENTRIES, which, if nonzero, limits the amount of entries to a user specified maximum. For backwards compatibility the default setting of 0 disables the limit. All changes to fdb_n_ent...

...I've started looking at the GlobalMerge pass, enabled by default on > > > ARM and AArch64. I think we should reconsider that, at least for > > > AArch64. > > > > > > As is, the pass just merges all globals together, in groups of 4KB > > > (AArch64, 128B on ARM). > > > > > > At the time it was enabled, the general thinking was "it's almost > > > free, it doesn't affect performance much, we might as well use it". > > > Now, it's preventing some link-time optimizations (as acknowledged in >...

...ext, or else we'll pay the context switch penalty. It might be too big an assumption to assume that movaps and vmovaps have the same timings. Same for moved. See above. > Also, I'm sure you are aware that the Sandybridge optimization guide suggests that unaligned stores be split into a 128b store and 128b extract. This does argue against my above assumption. This is true. The reason that they suggest that is so that you avoid storing over a page boundary which causes obscene slow downs. As an aside if you are doing any vector coding, you should always align the stores and use unalign...

...t we already have code in the backend that matches other horizontal operations (see isHorizontalBinOp and its callers in lib/Target/X86/X86ISelLowering.cpp), and I suspect this won't be significantly more complicated. > including the fact that we would need a > 4-way unroll to use all of 128b PSADBWs. Or am I > missing something ? No, each unrolling will get its own, so you'll get a PSADBW from each time the loop is unrolled. Each unrolling is vectorized in terms of <4 x i32>, and that is the 128 bits you need. If you'd like to contribute support for this, look at isH...

...] (bus address [0xc0000000-0xffffffff]) [ 1.110286] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400 [ 1.110505] pci 0000:00:00.0: PME# supported from D0 D3hot [ 1.114095] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 1.114343] pci 0000:01:00.0: [10de:128b] type 00 class 0x030000 [ 1.114404] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00ffffff] [ 1.114456] pci 0000:01:00.0: reg 0x14: [mem 0x00000000-0x07ffffff 64bit pref] [ 1.114510] pci 0000:01:00.0: reg 0x1c: [mem 0x00000000-0x01ffffff 64bit pref] [ 1.114551] pci 0000:01:00.0: reg 0x2...

...ndRegs:%vreg1 GPRegs:%vreg0 64B BRcondrel %vreg1<kill>, <BB#2>; CondRegs:%vreg1 80B BRrel <BB#1> Successors according to CFG: BB#1(12) BB#2(20) 96B BB#1: derived from LLVM BB %if.then Predecessors according to CFG: BB#0 112B %vreg3<def> = MOVri 1; GPRegs:%vreg3 128B STWi13 <fi#0>, 0, %vreg3<kill>; mem:ST4[%retval] GPRegs:%vreg3 144B BRrel <BB#3> Successors according to CFG: BB#3 160B BB#2: derived from LLVM BB %if.else Predecessors according to CFG: BB#0 176B %vreg2<def> = MOVri 0; GPRegs:%vreg2 192B STWi13 <fi#0>,...

...veins: $r0, $r1, $r2 16B %2:tgpr = COPY $r2 32B %1:tgpr = COPY $r1 48B %0:tgpr = COPY $r0 64B ADJCALLSTACKDOWN 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 80B %3:tgpr = tLDRpci %const.0, 14, $noreg :: (load 4 from constant-pool) 96B $r0 = COPY %0:tgpr 112B $r1 = COPY %1:tgpr 128B $r2 = COPY %2:tgpr 144B tBLXr 14, $noreg, %3:tgpr, <regmask $lr $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $q4 $q5 $q6 $q7 $r4 $r5 $r6 $r7 $r8 $r9 $r10 $r11 $s16 $s17 $s18 $s19 $s20 $s21 $s22 $s23 $s24 $s25 $s26 $s27 and 35 more...>, implicit-def dead $lr, implicit $sp, implicit $r0, implicit...

...2, implicit undef $eflags > 48B JMP_1 %bb.2 > > 64B bb.1: > successors: %bb.3(0x80000000); %bb.3(100.00%) > > 80B %1:gr32 = MOV32ri 17 > 96B JMP_1 %bb.3 > > 112B bb.2: > ; predecessors: %bb.0 > successors: %bb.3(0x80000000); %bb.3(100.00%) > > 128B NOOP implicit %0:gr32 > 144B %1:gr32 = COPY %0:gr32 > 160B JMP_1 %bb.3 > > 176B bb.3: > ; predecessors: %bb.1, %bb.2 > > 192B NOOP implicit %1:gr32 > > # End machine code for function somefunc. > > > If you look at the "intervals" (the cla...

...t;def> = COPY %C1_X; R600_Reg32:%vreg18 register: %vreg18 +[80r,128r:0) 96B%vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; R600_Reg128:%vreg19 R600_TReg32:%vreg14 register: %vreg19 +[96r,144r:0) 112B%vreg2<def> = COPY %C1_Y; R600_Reg32:%vreg2 register: %vreg2 +[112r,400r:0) 128B%vreg21:sel_x<def,read-undef> = COPY %vreg18<kill>; R600_Reg128:%vreg21 R600_Reg32:%vreg18 register: %vreg21 +[128r,176r:0) 144B%vreg23<def> = COPY %vreg19<kill>; R600_Reg128:%vreg23,%vreg19 register: %vreg23 +[144r,224r:0) 160B%vreg23:sel_y<def> = COPY %vreg15<kill&...

...vreg18 > register: %vreg18 +[80r,128r:0) > 96B%vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; > R600_Reg128:%vreg19 R600_TReg32:%vreg14 > register: %vreg19 +[96r,144r:0) > 112B%vreg2<def> = COPY %C1_Y; R600_Reg32:%vreg2 > register: %vreg2 +[112r,400r:0) > 128B%vreg21:sel_x<def,read-undef> = COPY %vreg18<kill>; > R600_Reg128:%vreg21 R600_Reg32:%vreg18 > register: %vreg21 +[128r,176r:0) > 144B%vreg23<def> = COPY %vreg19<kill>; R600_Reg128:%vreg23,%vreg19 > register: %vreg23 +[144r,224r:0) > 160B%vreg23:sel_y<def&g...