similar to: [LLVMdev] [rfc] "alias weak" X "weak alias"

>> The days of the old .ll parser are long gone, but is it too late to >> change? In case it is not, the attached patches implement just that >> :-) > I'm afraid you need to provide syntax autoupgrade until 4.0 Why, we moved to doing autoupgrade via bitcode quiet some time ago. There were quiet a few format changes to the .ll in the process. Cheers, Rafael

Dear R-Friends, Sorry to bother everyone with my earlier question: "Do we have similar R function to work like Minitab's INDICATOR?" I found the way to make things work: e.g., > x <- c(2,2,5,3,6,5,NA) > model.matrix(~ factor(x) - 1) factor(x)2 factor(x)3 factor(x)5 factor(x)6 1 1 0 0 0 2 1 0 0 0

Hi, new to R and ggplot2. I've been trying to get a facet plot in which the order of the facets is as I require, rather than ordered numerically, alphabetically, by Roman numerals, mean (answers to these were posted here after much searching). Here's some test code to demonstrate what I get. series = c('C2','C4','C8','C10','C15','C20') ids =

Hi All I am having 2 very long character strings (550chars) and I want to put them as expressions together with c(). The problem is that I also get these double-quotes, as seen below in 'fct'. How can I remove these double-quotes? I tried as.name() but it did not work (because of size?). These are creating trouble with subsequent programs, which I tested with strings that for some

Ultimately my aim is to get a plot of density faceted by 2 factors with a horizontal boxplot overlaid on each density plot in the grid to indicate summary stats. So I've been experimenting with creating boxplots and density plots. Here's some representative data. series = c('C2','C4','C8','C10','C15','C20') ids =

Hi All, I want to fit a straight line into a group of two-dimensional data points with errors in both x and y coordinates. I found there is an algorithm provided in "NUMERICAL RECIPES IN C" http://www.library.cornell.edu/nr/bookcpdf/c15-3.pdf I'm wondering if there is a similar function for this implemented in R. And how can I change the objective function, from example, from sum

Hi I am using the following script to average a set of data 0f 62 columns into 31 colums. The data consists of values of ln(0.01) or -4.60517 instead of NA's. These need to be averaged for each row (i.e 2 values being averaged). What I would I need to change for me to meet the conditions: 1. If each run of the sample has a value, the average is given 2. If only one run of the sample has a

Hi, On 23-03-16 23:10, Samuel Pitoiset wrote: > Are you sure this won't break compute shaders on fermi? > Could you please double-check that? I just checked: lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1) Before this patch-set: [hans at plank piglit]$ ./piglit run -o shader -t '.*arb_shader_storage_buffer_object.*' results/shader

hello, i can't figure out how to set position of panels of my stripplot - i`d like the panels of one level of the factor stage (nr. of panels within each stage, A: 12, B: 12, C: 12, D: 4, each panel representing a site) to be in one column, with A to D from left to right and with descending site.nr at each row. like: A1 B1 C1 D1 A2 B2 .. .. A3 .. .. .. how is this achieved? any help

I''ve filed this bug under util-linux, because I think wipefs isn''t deleting all btrfs metadata it could. But ultimately it appears to be a btrfs bug because nothing else sees the stale volume. https://bugzilla.redhat.com/show_bug.cgi?id=889888#c15 btrfs-progs-0.20.rc1.20121017git92d9eec-1.fc18.x86_64 e2fs-progs-1.42.5-1.fc18.x86_64 kernel 3.7.1-2 Brand new 80GB virtual disk,

Hi, On 08-04-16 18:14, Samuel Pitoiset wrote: > > > On 04/08/2016 12:17 PM, Hans de Goede wrote: >> Hi, >> >> On 23-03-16 23:10, Samuel Pitoiset wrote: >>> Are you sure this won't break compute shaders on fermi? >>> Could you please double-check that? >> >> I just checked: >> >> lspci: >> 01:00.0 VGA compatible

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it

With the case-insensitive file system patch from http://llvm.org/bugs/show_bug.cgi?id=9656#c15 applied to dragonegg 2.9, the following Polyhedron 2005 benchmarks are seen on x86_64-apple-darwin10 under gcc 4.5.3svn using the dragonegg plugin... ================================================================================ Date & Time : 8 Apr 2011 19:52:56 Test Name :

I agree with Paul that we need to formalise the compatibility policy before we start removing support for old intrinsics. Do we want a deprecation warning of some kind for the use of any intrinsic used in auto-upgrade, would that actually be useful or just a nuisance? In the meantime I’m happy to help fix any missing test coverage. > On 20 Sep 2017, at 22:16, Robinson, Paul via llvm-dev

Many of the older autoupgrades have no test cases because I think when we upgraded them we just replace all the code in the tests with native IR. So for some of the code we don't even know if it works. I don't really want to watch the amount of code here continue to grow indefinitely. It's pretty poorly structured and has been up against the MSVC cascaded if/else limit a couple times.

We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics that have been replaced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. 3.1 added upgrade for:

Hi, I believe we have a formal policy: we support every bitcode produced since LLVM 3.0: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility (until we decide to uprev the version we support). Unfortunately, the testing was only added around 3.6 or 3.7? And support is only as good as the testing we have... -- Mehdi 2017-09-21 0:23 GMT-07:00 Simon Pilgrim via llvm-dev <

Hi all, Please consider committing the attached patch. I believe the SSE2 packsswb, packssdw and packuswb intrinsics have an incorrect return type. Thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/85ed0b5e/attachment.html> -------------- next part -------------- A

>> >> At a minimum, it seems like we need a version number in the debug info >> metadata so we can detect this situation and avoid crashing. > > > Or to put it in the terms of the IR: we need to autoupgrade the debug info > metadata just like we do intrinsics. With debug info this might (at the > worst) involve dropping old metadata. > The verifier is probably

On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at