search for: t26

.... Could you provide the complete DAG before and after the erroneous transformation? -Krzysztof Combining: t25: v2i16 = BUILD_VECTOR t27, t22 Before reduceBuildVecToShuffle SelectionDAG has 14 nodes: t0: ch = EntryToken t2: v4i16,ch = CopyFromReg t0, Register:v4i16 %0 // [a b c d] t26: v2i16 = extract_subvector t2, Constant:i32<0> // [a b] t27: i16 = extract_vector_elt t26, Constant:i32<0> // [a] t21: v2i16 = extract_subvector t2, Constant:i32<2> //[c d] t22: i16 = extract_vector_elt t21, Constant:i32<0> // [c] t25: v2i16 = BUI...

Hi Guys We have a strange a strange issue at a client they have 3 panels on their phone and every so often the panels reboot themselves yet the phone stays on. We decided to replace the T26 for a T28 to see if it fixes the issue and still have the exact same issue. Has anyone seen this before? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150313/73f530c9/attachment.html>

Hi! > > We have a strange a strange issue at a client they have 3 panels on their phone and every so > often the panels reboot themselves yet the phone stays on. > > We decided to replace the T26 for a T28 to see if it fixes the issue and still have the exact > same issue. > > Has anyone seen this before? > I frequently use the newer T48G and T46G phones with the EXP40 expansion module. There are issues, if you are logged into the phone via the webinterface as an admin. Among...

Hi, Sorry for an OT post but striking out a bit at the moment trying to get a response from Yealink R&D. Has anybody successfully managed to get a Yealink phone to work across Open-VPN when using tlsauth ? We really do hope that it is possible due to the benefits tlsauth offers against DoS. -- Thanks, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL:

...balAddress:i16<float* @x1> 0, undef:i16 t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, GlobalAddress:i16<float* @x2> 0, undef:i16 t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, GlobalAddress:i16<float* @x3> 0, undef:i16 t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, GlobalAddress:i16<float* @x4> 0, undef:i16 t27: i16 = GlobalAddress<float (float, float, float, float)* @fdivfaddfmul_a> 0 t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> t31: ch,glue = CLPISD::...

...ng a new backend that I created for a new architecture. I suspect these errors may have something to do with how I have the string setup in LLVMTargetMachine() below? Also - It would be great if someone could point me to a document that describes some of these error messages? For example what does t26 ..t4 mean? Thanks in advance for taking your valuable time to help me! Jeff jeff at ubuntu:~/code$ llc dft_gf_msp.ll LLVM ERROR: Cannot select: t28: ch = store<ST2[%le](align=4), trunc to i16> t27, t26, FrameIndex:i32<14>, undef:i32 t26: i32,ch = load<LD2[%sz](align=4), anyext f...

...t; >   t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, > GlobalAddress:i16<float* @x2> 0, undef:i16 > >   t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, > GlobalAddress:i16<float* @x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = GlobalAddress<float (float, float, float, float)* > @fdivfaddfmul_a> 0 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i1...

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

...> >   t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, > GlobalAddress:i16<float* @x2> 0, undef:i16 > >   t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, > GlobalAddress:i16<float* @x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = GlobalAddress<float (float, float, float, float)* > @fdivfaddfmul_a> 0 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i16...

...;s phone is ringing, Asterisk updates Alice phone screen with Bob's name, so that at a glance, Alice can check she dialed the correct number. Before diving into Asterisk documentation, I would be happy to be confirmed if one of the following SIP phone support this feature : Aastra 57i Yealink T26 Cisco 525G Thomson ST2030S Regards

...t6: i64,ch,glue = CopyFromReg t4:1, Register:i64 %reg2, t4:1 t8: i64,ch,glue = CopyFromReg t6:1, Register:i64 %reg3, t6:1 t11: ch = CopyToReg t0, Register:i64 %vreg0, t2 t13: ch = CopyToReg t0, Register:i64 %vreg1, t4 t15: ch = CopyToReg t0, Register:i64 %vreg2, t8 t26: ch = TokenFactor t11, t13, t15, t2:1, t4:1, t6:1, t8:1 t16: i64 = sdiv t2, t4 Before legalization, there is a single sdiv node. After legalization, this has been expanded to a call sequence: t0: ch = EntryToken t2: i64,ch,glue = CopyFromReg t0, Register:i64 %reg0 t4: i64,ch,glue = Co...

I see we're missing an isel pattern for add producing carry and doing a memory RMW. I'm going to see if adding that helps anything. ~Craig On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yes. I'm seeing that as well. Not clear what's going on. > > In any case it looks to be unrelated to the alias analysis so barring

...et type is v2i16 or v4i16, and for other cases we just return the input SDValue and let the "normal" code handle it in whatever way it see fits. In this particular case, when it crashes, we have a bitcast from v2i64 to v4i32: t70: v4i32 = bitcast t27 and t27 is t27: v2i64 = or t15, t26 so it's a bitcast from v2i64 to v4i32 that we don't want to do anything special with so we return the input SDValue which TargetLowering::LowerOperationWrapper returns back to DAGTypeLegalizer::CustomLowerNode and then we get the assert in DAGTypeLegalizer::ReplaceValueWith. Thanks, M...

...= X86ISD::KORTEST t19, t19 t22: i8 = X86ISD::SETCC Constant:i8<4>, t21 t23: i32 = zero_extend t22 t14: ch,glue = CopyToReg t0, Register:i32 %EAX, t23 t24: i16,ch = load<LD1[%XXX](align=4)(dereferenceable), zext from i8> t0, FrameIndex:i64<0>, undef:i64 t26: i16 = AssertZext t24, ValueType:ch:i4 t19: v16i1 = bitcast t26 t15: ch = X86ISD::RET_FLAG t14, TargetConstant:i32<0>, Register:i32 %EAX, t14:1 -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation...

...Constant:i64<-1>, Constant:i64<-2>, Constant:i64<-3>, Constant:i64<-4>, Constant:i64<-5>, Constant:i64<-6>, Constant:i64<-7> t56: v8i64 = add t47, t55 t17: i64 = extract_vector_elt t16, Constant:i64<0> t26: ch = CopyToReg t0, Register:i64 %vreg16, t17 t18: i64 = extract_vector_elt t16, Constant:i64<1> t28: ch = CopyToReg t0, Register:i64 %vreg17, t18 t19: i64 = extract_vector_elt t16, Constant:i64<2> t30: ch = CopyToR...

On Thu, Oct 20, 2016 at 12:05 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Oct 20, 2016, at 8:54 AM, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hey guys, >> >> I've hit a pretty nasty issue on SKX with ANDs of masks <= 4 bits. >> >> In the IR, we represent a 4b vector mask as <4 x i1>.

...AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 6/21/2016 11:12 AM, Jeff E via llvm-dev wrote: > >> >> Also - It would be great if someone could point me to a document that >> describes some of these error messages? For example what does t26 ..t4 >> mean? >> > > The t.. are just identifiers of the DAG nodes. It used to print addresses, > but they were long and would change every time. > > The "cannot select" errors are not that hard to track down: compile the > failing testcase with -debug-only=i...

...Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, ... Combining: t10: v128i64 = zero_extend t25 ... into: t26: v128i64 = BUILD_VECTOR Constant:i64<31>, Constant:i64<31>, Constant:i64<31>, Constant:i64<31> Once I have defined type v128i64 in the above mentioned 4 files (2 .td, 1 .h, 1 .cpp), I no longer get this strange error. However, now I start getting Segfault at selectio...

...56[<unknown>]> t0, t23, t40, TargetConstant:i64<0>, t24 Widen node result 0: t46: v64i16 = extract_subvector t23, Constant:i64<64> Widen node result 0: t48: v64i16,ch = masked_gather<LD128[<unknown>](align=256)> t0, t46, t44, TargetConstant:i64<0>, t26 Split node result: t121: v128i64 = BUILD_VECTOR Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64<0>, Constant:i64&l...

Hi, I'm a litle bit puzzled by the TargetLowering::LowerOperation function, and what different callers of this function assumes about the returned value. In several places it seems like it is assumed that LowerOperation can return three kinds of values: * Something completely new. * SDValue() * The same SDValue as LowerOperation was called on. However in some places, e.g. in