search for: combinelevels

Hi, The add.with.overflow instrinsics don't seem to work with constant arguments, i.e. changing the call in add-with-overflow.ll to: %t = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 0, i32 0) causes the following exception when running the codegen tests: llc: DAGCombiner.cpp:646: void<unnamed>::DAGCombiner::Run(llvm::CombineLevel): Assertion `N->getValueType(0) ==

Hi all, The DAGCombiner pass actually runs even if the optimize level is set to None. This can result in incorrect debug information or unexpected stepping/debugging experience. Not to mention that having good stepping/debugging experience is the major reason to compile at /O0. I recently suggested a patch to disable one specific DAG combine at /O0 that broke stepping on a particular case

To extwnd on Martin 's explanation : In factor(), levels are the unique input values and labels the unique output values. So the function levels() actually displays the labels. Cheers Joris On 15 Jun 2017 17:15, "Martin Maechler" <maechler at stat.math.ethz.ch> wrote: >>>>> Paul Johnson <pauljohn32 at gmail.com> >>>>> on Wed, 14 Jun

Applied. Thanks, Zoltan! -bw On Tue, Dec 9, 2008 at 1:12 PM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > Attached is the final version of the patch, adding the requested > FIXME. If this is ok, can > somebody check it in ? > > thanks > > Zoltan > > On Tue, Dec 9, 2008 at 9:58 PM,

...uot;male", "Female")) > levels(xf) <- c("Male", "Male", "Male", "Female") > I think it is quirky that `levels<-.factor` allows the duplicated > labels, whereas factor does not. > I wrote a function rockchalk::combineLevels to simplify combining > levels, but most of the students here like plyr::mapvalues to do it. > The use of levels() can be tricky because one must enumerate all > values, not just the ones being changed. > But I do understand Martin's point. Its been this way 25 year...

...le")) >>> levels(xf) <- c("Male", "Male", "Male", "Female") > >>> I think it is quirky that `levels<-.factor` allows the duplicated >>> labels, whereas factor does not. > >>> I wrote a function rockchalk::combineLevels to simplify combining >>> levels, but most of the students here like plyr::mapvalues to do it. >>> The use of levels() can be tricky because one must enumerate all >>> values, not just the ones being changed. > >>> But I do understand Martin's point. Its...

Hi, Attached is the final version of the patch, adding the requested FIXME. If this is ok, can somebody check it in ? thanks Zoltan On Tue, Dec 9, 2008 at 9:58 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: >> Hi, >>

...quot;Male", "Man", "male", "Female")) levels(xf) <- c("Male", "Male", "Male", "Female") I think it is quirky that `levels<-.factor` allows the duplicated labels, whereas factor does not. I wrote a function rockchalk::combineLevels to simplify combining levels, but most of the students here like plyr::mapvalues to do it. The use of levels() can be tricky because one must enumerate all values, not just the ones being changed. But I do understand Martin's point. Its been this way 25 years, it won't change. :). > Ch...

..."Female")) >> levels(xf) <- c("Male", "Male", "Male", "Female") >> I think it is quirky that `levels<-.factor` allows the duplicated >> labels, whereas factor does not. >> I wrote a function rockchalk::combineLevels to simplify combining >> levels, but most of the students here like plyr::mapvalues to do it. >> The use of levels() can be tricky because one must enumerate all >> values, not just the ones being changed. >> But I do understand Martin's point. Its been...

...;> levels(xf) <- c("Male", "Male", "Male", "Female") >> >>>> I think it is quirky that `levels<-.factor` allows the duplicated >>>> labels, whereas factor does not. >> >>>> I wrote a function rockchalk::combineLevels to simplify combining >>>> levels, but most of the students here like plyr::mapvalues to do it. >>>> The use of levels() can be tricky because one must enumerate all >>>> values, not just the ones being changed. >> >>>> But I do understand Marti...

Hi, DAG combiner does indeed optimizations but also canonicalization. The latter, we probably need to keep, the former, we should be able to disable. When I asked Marianne to do a RFC about this, I was hoping we could get new ideas on how to tackle this problem. I am fine with the approach of disabling the optimizations one by one when we know it is indeed an optimization. However, I am not a