search for: cu2

Hi all, I have a data frame with "clustered" rows as follows: Cu1 x1 y1 z1 ... Cu1 x2 y2 z2 ... Cu1 x3 y3 z3 ... # end of first cluster Cu1 Cu2 x4 y4 z4 ... Cu2 x5 y5 z5 Cu2 ... # end of second cluster Cu2 Cu3 ... ... "cluster"-size is 3 in the example above (rows making up a cluster are always consecutive). Is there any faster way to sample n clusters (with replacement) from this dataframe and build up a new dat...

..., right - I can see how it reads that way, sorry. Old old way: first.ll: CU1 -> {fn1_SP -> @fn1, inl_SP -> @inl, ... } @fn1 ... @inl ... Resulting DWARF: compile_unit CU1 subprogram fn1 high/low pc, etc subprogram inl high/low pc, etc second.ll: CU2 -> {inl_SP2 -> @inl, SP2 -> @fn2, ... } @inl ... @fn2 ... Resulting DWARF: compile_unit CU2 subprogram inl high/low pc, etc subprogram fn2 high/low pc, etc link first.ll + second.ll: CU1 -> {fn1_SP -> @fn1, inl_SP -> @inl, ... } CU2 ->...

...> first.ll: > CU1 -> {fn1_SP -> @fn1, inl_SP -> @inl, ... } > @fn1 ... > @inl ... > Resulting DWARF: > compile_unit CU1 > subprogram fn1 > high/low pc, etc > subprogram inl > high/low pc, etc > > second.ll: > CU2 -> {inl_SP2 -> @inl, SP2 -> @fn2, ... } > @inl ... > @fn2 ... > Resulting DWARF: > compile_unit CU2 > subprogram inl > high/low pc, etc > subprogram fn2 > high/low pc, etc > > link first.ll + second.ll: > CU1 -> {f...

...> first.ll: > CU1 -> {fn1_SP -> @fn1, inl_SP -> @inl, ... } > @fn1 ... > @inl ... > Resulting DWARF: > compile_unit CU1 > subprogram fn1 > high/low pc, etc > subprogram inl > high/low pc, etc > > second.ll: > CU2 -> {inl_SP2 -> @inl, SP2 -> @fn2, ... } > @inl ... > @fn2 ... > Resulting DWARF: > compile_unit CU2 > subprogram inl > high/low pc, etc > subprogram fn2 > high/low pc, etc > > link first.ll + second.ll: > CU1 -> {f...

...t; @fn1, inl_SP -> @inl, ... } >> @fn1 ... >> @inl ... >> Resulting DWARF: >> compile_unit CU1 >> subprogram fn1 >> high/low pc, etc >> subprogram inl >> high/low pc, etc >> >> second.ll: >> CU2 -> {inl_SP2 -> @inl, SP2 -> @fn2, ... } >> @inl ... >> @fn2 ... >> Resulting DWARF: >> compile_unit CU2 >> subprogram inl >> high/low pc, etc >> subprogram fn2 >> high/low pc, etc >> >> link f...

On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: > >> Trying to wrap my brain around this, so a few questions below. =) >> > > Sure thing - sorry, did assume a bit too much arcane context here. > > >> >> On Thu, Dec

...we're not going to be able to make >> debug info as compact as we can with your current change, not without more >> work, at least. >> >> Taking the implicit special member example, CU1 would have the definition >> of some type 'foo' and its normal members. CU2 has a declaration of 'foo' >> (or perhaps another definition, depending on whether it's a polymorphic >> type, etc) and the implicit special member definition (such as the copy >> ctor). When we do the right type referencing and uniquing at the metadata >> level...

...e? > If we do one-CU-at-a-time emission we're not going to be able to make debug info as compact as we can with your current change, not without more work, at least. Taking the implicit special member example, CU1 would have the definition of some type 'foo' and its normal members. CU2 has a declaration of 'foo' (or perhaps another definition, depending on whether it's a polymorphic type, etc) and the implicit special member definition (such as the copy ctor). When we do the right type referencing and uniquing at the metadata level what's going to happen (I think)...

...-at-a-time emission we're not going to be able to make > debug info as compact as we can with your current change, not without more > work, at least. > > Taking the implicit special member example, CU1 would have the definition > of some type 'foo' and its normal members. CU2 has a declaration of 'foo' > (or perhaps another definition, depending on whether it's a polymorphic > type, etc) and the implicit special member definition (such as the copy > ctor). When we do the right type referencing and uniquing at the metadata > level what's going...

...we're not going to be able to make >> debug info as compact as we can with your current change, not without more >> work, at least. >> >> Taking the implicit special member example, CU1 would have the definition >> of some type 'foo' and its normal members. CU2 has a declaration of 'foo' >> (or perhaps another definition, depending on whether it's a polymorphic >> type, etc) and the implicit special member definition (such as the copy >> ctor). When we do the right type referencing and uniquing at the metadata >> level...

On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > > In beginModule, we construct the CUs, but not all the DIEs that belong >>>> to the CU. >>>> In endFunction, we started to construct the scope DIEs. So in some >>>> sense, we are adding things to prior CUs. >>>> >>>> Looking at void

> In beginModule, we construct the CUs, but not all the DIEs that belong to >>> the CU. >>> In endFunction, we started to construct the scope DIEs. So in some >>> sense, we are adding things to prior CUs. >>> >>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t Attribute, >>> DIE *Entry), we can possibly have 3 CUs, this CU,