search for: t31

.... -I. -I -g -O2 -MT t30.lo -MD -MP -MF .deps/t30.Tpo -c t30.c -fPIC -DPIC -o .libs/t30.o gcc -DHAVE_CONFIG_H -I. -I. -I. -I -g -O2 -MT t30.lo -MD -MP -MF .deps/t30.Tpo -c t30.c -o t30.o >/dev/null 2>&1 if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I -g -O2 -MT t31.lo -MD -MP -MF ".deps/t31.Tpo" -c -o t31.lo t31.c; \ then mv -f ".deps/t31.Tpo" ".deps/t31.Plo"; else rm -f ".deps/t31.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I. -I -g -O2 -MT t31.lo -MD -MP -MF .deps/t31.Tpo -c t31.c -fPIC -DPIC -o .libs/t31.o t31.c:...

...initial selection DAG has the AND op node: t22: i8 = srl t19, Constant:i64<1> * t23: i8 = and t22, Constant:i8<1>* t24: i32 = zero_extend t23 t27: i1 = setcc t24, Constant:i32<1>, seteq:ch t29: i1 = xor t27, Constant:i1<-1> t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> The Optimized lowered selection DAG does not contain the* AND* node, but it does have a truncate which would seem to stand in for it given the result is only 1bit wide and the x...

...op node: > > t22: i8 = srl t19, Constant:i64<1> > * t23: i8 = and t22, Constant:i8<1>* > t24: i32 = zero_extend t23 > t27: i1 = setcc t24, Constant:i32<1>, seteq:ch > t29: i1 = xor t27, Constant:i1<-1> > t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> > t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> > > The Optimized lowered selection DAG does not contain the*AND* node, > but it does have a truncate which would seem to stand in for it given > the result is...

...op node: > > t22: i8 = srl t19, Constant:i64<1> > * t23: i8 = and t22, Constant:i8<1>* > t24: i32 = zero_extend t23 > t27: i1 = setcc t24, Constant:i32<1>, seteq:ch > t29: i1 = xor t27, Constant:i1<-1> > t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> > t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> > > The Optimized lowered selection DAG does not contain the* AND* node, but > it does have a truncate which would seem to stand in for it given the > result is...

...> 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::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>, t29:1 t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16<1>, t31:1 t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>, t33:1 t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, Fram...

...le 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::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>, > t29:1 > >   t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16<1>, > t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>, > t33:1 > >  ...

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

...; <uint> [#uses=1] %.t25 = shr uint %.t22, ubyte 26 ; <uint> [#uses=1] %.t28 = getelementptr [64 x ubyte]* %table, int 0, uint %.t25 ; <ubyte*> [#uses=1] %.t28 = load ubyte* %.t28 ; <ubyte> [#uses=1] %.t31 = cast ubyte %.t28 to int ; <int> [#uses=1] ret int %.t31 } This is the disassembled output after running the optimizer. How can %.t28 be written to twice? That isn't my understanding of SSA. Here's another similar situation: %x.2.i73 = cast uint %x.2.i73...

...ile 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::COPY_TO_CALLEE_A t29, t23, > FrameIndex:i16<0>, > t29:1 > >   t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, > FrameIndex:i16<1>, > t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, > FrameIndex:i16<2>, > t33:1...

...arr[4]; arr[0] = 0xAA; arr[1] = 0xBB; arr[2] = 0xCC; arr[3] = 0xDD; return *(int*)&arr[0]; } The memory operation in "return" statement ends up transformed into 4-byte load in the initial DAG: load<(dereferenceable load 4 from %ir.7, align 1, addrspace 1)> t31, FrameIndex:i32<0>, ... However, at the "Legalized selection DAG" stage things go differently, depending on the OS I'm running. On Windows this load stay in its previous form, but on FreeBSD this load gets turned into 1-byte loads for some reason: load<(dereferenceable load...

Hi, I have a problem that dbg_value nodes are not transferred when integer DAG nodes are promoted. For example, an i32 add node is promoted to a i64 add node by DAGTypeLegalizer::PromoteIntegerResult and its dbg_value node is not transferred to the new node. t9: i32 = add nsw t5, t8 --> t31: i64 = add t30, t7 ; the dbg_value node is not transferred to the new i64 add node. For expansion, DAGTypeLegalizer::SetExpandedInteger calls transferDbgValues() but I couldn't find any place to call trasnferDbgValues() for integer type promotion in DAGTypeLegalizer ::SetPromotedInteger and...

...CTOR Constant:i32<0>, Constant:i32<-23> t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 t22: i32 = add t15, Constant:i32<1> t24: ch = CopyToReg t0, Register:i32 %vreg3, t22 t27: ch = CopyToReg t0, Register:i32 %vreg8, Constant:i32<-1> t31: ch = TokenFactor t24, t27 t13: v2i1 = setcc t8, t11, setne:ch t16: i1 = extract_vector_elt t13, t15 t17: i32 = extract_vector_elt t8, t15 t18: i32 = extract_vector_elt t11, t15 t19: i1 = setcc t17, t18, setne:ch t20: i1 = xor t1...

...before the doSmth function call, t30: i16 = CMPkr16 t4, TargetConstant:i16<0> t36: ch,glue = CopyToReg t0, Register:i16 $sr, t30 t32: i16 = NEGSETCC TargetConstant:i16<4>, t36:1 And this is generated after the call t35: ch,glue = CopyToReg t0, Register:i16 $sr, t30 t31: i16 = SELCC t19, t18, TargetConstant:i16<4>, t35:1 t21: ch,glue = CopyToReg t18:1, Register:i16 $r0, t31 NEGSETCC and SELCC are genuine instructions of my target architecture, they use the SR along with operands to produce a result. As you can see ‘t30’ is used both before and after the...

On Thu, 11 Jan 2007, Schimmel, Mark wrote: > file://docs/LangRef.html#globalvars > > The section describing the definition of global vars discusses that you > can specify an alignment and can also specify a section. Could someone > provide an example that works in gccas in release 1.9 for both defining > which section the var is assigned to and defining the variables >

...gt; I have a problem that dbg_value nodes are not transferred when integer DAG nodes are promoted. For example, an i32 add node is promoted to a i64 add node by DAGTypeLegalizer::PromoteIntegerResult and its dbg_value node is not transferred to the new node. > > t9: i32 = add nsw t5, t8 à t31: i64 = add t30, t7 ; the dbg_value node is not transferred to the new i64 add node. > > For expansion, DAGTypeLegalizer::SetExpandedInteger calls transferDbgValues() but I couldn’t find any place to call trasnferDbgValues() for integer type promotion in DAGTypeLegalizer ::SetPromotedInteg...

...t;96> t22: i64 = Constant<0> t24: v4i32,ch = load<LD16[%0](align=8)(dereferenceable)> t20, FrameIndex:i64<1>, undef:i64 t27: i64 = add FrameIndex:i64<1>, Constant:i64<16> t28: v4i32,ch = load<LD16[%0+16](align=8)(dereferenceable)> t20, t27, undef:i64 t31: i64 = add FrameIndex:i64<1>, Constant:i64<32> t32: v4i32,ch = load<LD16[%0+32](align=8)(dereferenceable)> t20, t31, undef:i64 t36: i64 = add FrameIndex:i64<1>, Constant:i64<48> t37: v4i32,ch = load<LD16[%0+48](align=8)(dereferenceable)> t20, t36, undef:i64...

...ote: Hi, I have a problem that dbg_value nodes are not transferred when integer DAG nodes are promoted. For example, an i32 add node is promoted to a i64 add node by DAGTypeLegalizer::PromoteIntegerResult and its dbg_value node is not transferred to the new node. t9: i32 = add nsw t5, t8 --> t31: i64 = add t30, t7 ; the dbg_value node is not transferred to the new i64 add node. For expansion, DAGTypeLegalizer::SetExpandedInteger calls transferDbgValues() but I couldn’t find any place to call trasnferDbgValues() for integer type promotion in DAGTypeLegalizer ::SetPromotedInteger and othe...

file://docs/LangRef.html#globalvars The section describing the definition of global vars discusses that you can specify an alignment and can also specify a section. Could someone provide an example that works in gccas in release 1.9 for both defining which section the var is assigned to and defining the variables alignment? Also, is there another document that describes how you define sections

...i16 = CMPkr16 t4, TargetConstant:i16<0> > t36: ch,glue = CopyToReg t0, Register:i16 $sr, t30 > t32: i16 = NEGSETCC TargetConstant:i16<4>, t36:1 > > > And this is generated after the call > > t35: ch,glue = CopyToReg t0, Register:i16 $sr, t30 > t31: i16 = SELCC t19, t18, TargetConstant:i16<4>, t35:1 > t21: ch,glue = CopyToReg t18:1, Register:i16 $r0, t31 > > NEGSETCC and SELCC are genuine instructions of my target architecture, they use the SR along with operands to produce a result. > > As you can see ‘t30’ is used...

...;0>, Constant:i32<-23> > t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 > t22: i32 = add t15, Constant:i32<1> > t24: ch = CopyToReg t0, Register:i32 %vreg3, t22 > t27: ch = CopyToReg t0, Register:i32 %vreg8, Constant:i32<-1> > t31: ch = TokenFactor t24, t27 > t13: v2i1 = setcc t8, t11, setne:ch > t16: i1 = extract_vector_elt t13, t15 > t17: i32 = extract_vector_elt t8, t15 > t18: i32 = extract_vector_elt t11, t15 > t19: i1 = setcc t17, t18, setne:ch >...