search for: unmerg

...'t attend the round table yesterday, here is quick summary: One problem that some of us are seeing in the legalizer is that sometimes instructions get expanded before they get folded away in the combiner. IIRC Matt sees this happening with division, while I am seeing something similar with unmerge. To my particular problem: due to the nature of the architecture I'm working with, we have pretty strict legalization rules. One example is that we only allow unmerges from 64 to 32 bit. Unmerges of 32-bit or less get lowered to bit-arithmetic. However if we would do the same for anything...

Dear "R Gurus", I am having two dummy csv data sets A and B containing 19 and 15 cases/observations respectively. From the two data set 13 cases are intersection. From one of the two (any) data set, How do I then retrieve the unmerged data ? let's take A for example, six cases must appear in our results. See the R codes below. Please assist. Looking forward to hearing from the group sooner and thanking you in advance Kind regards Mangalani Peter Makananisa Statistical Analyst South African Revenue Service...

Hi, I’m trying to handle some vector operations with splitting/scalarization and keep running into similar sorts of issues which are making me question the intended function of the various legalization operations (particularly G_MERGE_VALUES/G_UNMERGE_VALUES, but also G_EXTRACT/G_INSERT and conversion instructions) and what the contract between the legalizer and selector actually is. For scalar values, things seem clearer, but I’m still confused. The AArch64 selector code seems content to allow strange sized values in the source of G_EXTRACT/G...

...-c "git rev-list --all | wc -l" So from the shell: $ git buildnum 17475 This number increases monotonically per commit. Our build scripts make this number available in various #define forms. (We use a little extra scripting logic to also determine whether there are currently any unmerged or uncommitted changes, and add an annotation to the program version in that case, e.g. "9.3.17475 [unmerged]") It's all stupidly simple, but seems to work well enough for us. Regards, Bill

Hello, I am attempting to merge 8 different data sets into a "grand merge" data set; all their variable names are common except for the the gas measured. However, when I did a quick stat summary comparison of merged data with unmerged data, it turned out that R mysteriously duplicated thousands of values in the merged set and I have no idea why. I've not had this problem with merge in the past.... any thoughts? To illustrate: given the following objects (as data frames) with 1 unique and 10 common variables: h2_flasks co...

...;ll print in the clang repo?), which I believe is something important considering our setup. -- Mehdi > > > Our build scripts make this number available in various #define forms. > > (We use a little extra scripting logic to also determine whether there > are currently any unmerged or uncommitted changes, and add an annotation > to the program version in that case, e.g. "9.3.17475 [unmerged]") > > > It's all stupidly simple, but seems to work well enough for us. > > > > Regards, > > Bill > > _________________________...

...nience than anything else.) --paulr > > -- > Mehdi > > > > > > > > > Our build scripts make this number available in various #define forms. > > > > (We use a little extra scripting logic to also determine whether there > > are currently any unmerged or uncommitted changes, and add an annotation > > to the program version in that case, e.g. "9.3.17475 [unmerged]") > > > > > > It's all stupidly simple, but seems to work well enough for us. > > > > > > > > Regards, > > > &g...

..., r168181 and r168291 as one reassociate changeset: Have you heard from Chris regarding r168291? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156364.html Pawel > On 20/11/12 05:57, Chris Lattner wrote: >> Fwiw, I approve both of these patches if they are still unmerged. > ... >>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155994.html >>> >>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.html >>> > > Thanks Chris. Can you please also give your go ahead for this...

...>> -- >> Mehdi >> >> >> >>> >>> >>> Our build scripts make this number available in various #define forms. >>> >>> (We use a little extra scripting logic to also determine whether there >>> are currently any unmerged or uncommitted changes, and add an annotation >>> to the program version in that case, e.g. "9.3.17475 [unmerged]") >>> >>> >>> It's all stupidly simple, but seems to work well enough for us. >>> >>> >>> >>&g...

...gt; > >> > >> > >>> > >>> > >>> Our build scripts make this number available in various #define forms. > >>> > >>> (We use a little extra scripting logic to also determine whether there > >>> are currently any unmerged or uncommitted changes, and add an > annotation > >>> to the program version in that case, e.g. "9.3.17475 [unmerged]") > >>> > >>> > >>> It's all stupidly simple, but seems to work well enough for us. > >>> > >&g...

...ttp://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156364.html No, he didn't OK it yet. Hopefully he will! Ciao, Duncan. > > Pawel > > > > >> On 20/11/12 05:57, Chris Lattner wrote: >>> Fwiw, I approve both of these patches if they are still unmerged. >> ... >>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155994.html >>>> >>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.html >>>> >> >> Thanks Chris. Can you please also...

Fwiw, I approve both of these patches if they are still unmerged. -Chris On Nov 18, 2012, at 11:41 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, > >>> Can you provide some examples of the problems you are seeing? >> >> Here is what happens. >> >> I get a message "could you please include/add/m...

...2013 12:55:17 -0700 Kent Overstreet <kmo at daterainc.com> wrote: > Fixup patch, addressing Andrew's review feedback: Looks reasonable. > lib/idr.c | 38 +++++++++++++++++++++----------------- I still don't think it should be in this file. You say that some as-yet-unmerged patches will tie the new code into the old ida code. But will it do it in a manner which requires that the two reside in the same file?

...2013 12:55:17 -0700 Kent Overstreet <kmo at daterainc.com> wrote: > Fixup patch, addressing Andrew's review feedback: Looks reasonable. > lib/idr.c | 38 +++++++++++++++++++++----------------- I still don't think it should be in this file. You say that some as-yet-unmerged patches will tie the new code into the old ida code. But will it do it in a manner which requires that the two reside in the same file?

...() right after lto_codegen_add_module() to help reduce the memory footprint. That would be a simple linker change. A slightly larger linker change would be to immediately call lto_codegen_add_module() right after lto_module_create_from_memory(), then lto_module_dispose(). That is, never have any unmerged modules laying around. I have no idea is these sort of changes work for the gold plugin. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/449ee352/attachment.html>

On 20/11/12 05:57, Chris Lattner wrote: > Fwiw, I approve both of these patches if they are still unmerged. ... >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155994.html >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.html Thanks Chris. Can you please also give your go ahead for this nasty reassociate infinite loop (PR14060): http...

...21112/156364.html > > No, he didn't OK it yet. Hopefully he will! > > Ciao, Duncan. > >> >> Pawel >> >> >> >> >>> On 20/11/12 05:57, Chris Lattner wrote: >>>> Fwiw, I approve both of these patches if they are still unmerged. >>> ... >>>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155994.html >>>>> >>>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.html >>>>> >>> >>> Than...

...odegen_add_module() to help reduce the memory footprint. That would be > a simple linker change. A slightly larger linker change would be to > immediately call lto_codegen_add_module() right after > lto_module_create_from_memory(), then lto_module_dispose(). That is, never > have any unmerged modules laying around. > > I have no idea is these sort of changes work for the gold plugin. The gold plugin calls lto_codegen_add_module/lto_module_dispose early. So it looks like Chandler's idea would be a win for gold but a loss for ld64 right now. Cheers, Rafael

Hi list! Just wondering, why is * sticking with an mpg123 version from the stoneage? Gentoo comes with 0.59s-r8 and this version doesn't even start. Ik know I could forcibly unmerge mpg123 and install the old version but I guess some day newer versions will have to be supported? Thanks!

I've recently returned to working on FreeDOS again after quite some time, and read about an unmerged MEMDISK branch that allows to boot DOS-based ISOs. This seemed quite usefull to me as it allows for faster modifications to my code/scripts/disklayout. The general idea was to install Syslinux 3.83 to harddisk, then add the modified Memdisk from that boot-land forum, as well as my ISO. In the...