similar to: Wrong code bug after GVN/PRE?

Yeah, there's a lot of things this could be. On the memdep side: Note that memdep is not actually properly updated in all cases by most passes that claim to not invalidate it (they don't invalidate dependent pointers, only pointers they directly touch). There's already a bug filed about this. So far we've only seen missed-opt, not wrong code from this. But it should be possible

Hi Devs, Consider below testcase. $cat test.cpp #include <vector> #include<type_traits> typedef int _int4 __attribute__((vector_size(16))); typedef union{ int data[4]; struct {int x, y, z, w;}; _int4 vec; } int4; typedef int4 int3; int main() { static_assert(std::alignment_of<int4>::value <= alignof(max_align_t), "over aligned!"); } $clang++ -m32 error:

Hi, I'm trying to assemble the following LLVM assembly source code, but llvm-as reports an error (expected opcode instruction) at the label "Until2:" (in function @find). If i remove both the load and store instructions before it it works, but then there is the same problem with Until1 (in @main). I wanted to ask how to solve this / where labels can be placed? @.intFormat = internal

Dear list, Being new to both the postgres database, ODBC and the RODBC interface, I am somewhat confused by some of the problems I am experiencing trying to connect R to the database. Whai I am trying is basically the example part of the help file for the sqlSave function: > library(RODBC) > odbcConnect("theodor") -> channel > data(USArrests) > sqlSave(channel,

Right, they are identifiers. Storing them as String has drawbacks: - huge to store in memory - slow to process - huge to index (by eg data.table columns indexes) Why not storing them as numeric ? Thanks, Le 20 janv. 2017 ? 18h16, William Dunlap ?crivait : > If these are identifiers, store them as strings. If not, what sort of > calculations do you plan on doing with them? > Bill

After chatting on IRC, Peter wants a very specific interrupt (int4 on x86). I suggested he add a new llvm.x86.int(i32) intrinsic, and use the existing branch on llvm.sadd.with.overflow intrinsic. The x86 backend can then turn jo+int4 into into when reasonable. -Chris On Aug 9, 2010, at 5:45 PM, Chris Lattner wrote: > > On Aug 9, 2010, at 10:44 AM, Peter S. Housel wrote: > >>

The lack of 64 bit integer support causes lots of problems when dealing with certain types of data where the loss of precision from coercing to 53 bits with double is unacceptable. Two packages were developed to deal with this: int64 and bit64. You may need to find archival versions of these packages if they've fallen off cran. Murray (mobile phone) On Jan 20, 2017 7:20 AM, "Gabriel

2^53 == 2^53+1 TRUE Which makes joining or grouping data sets with 64 bit identifiers problematic. Murray (mobile) On Jan 20, 2017 9:15 AM, "Nicolas Paris" <nicolas.paris at aphp.fr> wrote: Le 20 janv. 2017 ? 18h09, Murray Stokely ?crivait : > The lack of 64 bit integer support causes lots of problems when dealing with > certain types of data where the loss of precision

I am not on R-core, so cannot speak to future plans to internally support int8 (though my impression is that there aren't any, at least none that are close to fruition). The standard way of dealing with whole numbers too big to fit in an integer is to put them in a numeric (double down in C land). this can represent integers up to 2^53 without loss of precision see (

The enclosed patch adds a llvm.x86.int(i8) intrinsic expanding to the INT or INT3 instruction as appropriate. I haven't yet figured out the best way to select for the INTO instruction across basic blocks (hints would be welcome), but that can be added later with no changes in semantics. -Peter- On Aug 9, 2010, at 6:05 PM, Chris Lattner wrote: > After chatting on IRC, Peter wants a very

How many unique idenfiiers do you have? If they are large (in terms of bytes) but you don't have that many of them (eg the total possible number you'll ever have is < INT_MAX), you could store them as factors. You get the speed of integers but the labeling of full "precision" strings. Factors are fast for joins. ~G On Fri, Jan 20, 2017 at 9:47 AM, Nicolas Paris

To summarise this thread, there are basically three ways of handling int64 in R: * coerce to character * coerce to double * store in double There is no ideal solution, and each have pros and cons that I've attempted to summarise below. ## Coerce to character This is the easiest approach if the data is used as identifiers. It will have some performance drawbacks when loading and will

Hello r users, I have to deal with int8 data with R. AFAIK R does only handle int4 with `as.integer` function [1]. I wonder: 1. what is the better approach to handle int8 ? `as.character` ? `as.numeric` ? 2. is there any plan to handle int8 in the future ? As you might know, int4 is to small to deal with earth population right now. Thanks for you ideas, int8 eg: human_id

Hi, I do have < INT_MAX. This looks attractive but since they are unique identifiers, storing them as factor will be likely to be counter-productive. (a string version + an int32 for each) I was looking to https://cran.r-project.org/web/packages/csvread/index.html This looks like a good feet for my needs. Any chances such an external package for int64 would be integrated in core ? Le 20

Hi, I've found a case I would expect would optimize easily, but it doesn't. A simple implementation of vector select: float4 simple_select(float4 a, float4 b, int4 c) { float4 result; result.x = c.x ? a.x : b.x; result.y = c.y ? a.y : b.y; result.z = c.z ? a.z : b.z; result.w = c.w ? a.w : b.w; return result; } I would expect this would be optimized to %bool

Hi We have a few questions regarding the use of the "isoMDS" function. When we run "isoMDS" function using 60,000 x 60,000 data matrix, we get the following error message: ------------------------------------ cmdscale(d, k) : invalid value of 'n' Calls: isoMDS -> cmdscale ------------------------------------ We checked the source code of "cmdscale" and

Well I definitely cannot use them as numeric because join is the main reason of those identifiers. About int64 and bit64 packages, it's not a solution, because I am releasing a dataset for external users. I cannot ask them to install a package in order to exploit them. I have to be very carefull when releasing the data. If a user just use read.csv functions, they by default cast the

The structure of the file is clear (see below) the first line is made of integers and doubles with the fifth being a text string followed by arrays of double precision number.: int1 int2 double1 double2 text int3 int4 int5 (array of double) here is an example of file: 1 1 1.0 1.0 "HEAD" 160 224 3 23.4 34.5 ...... I tried to read the first line with readBin (results are copied below):

Hi, I am trying to run some bootstraps with the boot package. When I run it with 400 replicates it does it ok, but then I need to run the same analysis but with 89, 86, 102 and 106 samples (for four different environments), and then is when I get the error message: > mybootstrap <- boot(Datos, mystat, 2000) Error in t.star[r, ] <- statistic(data, i[r, ], ...) : number of items to

Hi All, I am encountering the following error "assigning to 'uint4' from incompatible type 'int __attribute__((ext_vector_type(4)))'" for code, p = q < (uint4)2; where p and q are of type uint4 The explicit type casting before assignement [p = (unit4)(q < (uint4)2)] resolves the error. In Clang Rev 2.9, there was no error for such code. Avoiding this implicit