similar to: [RFC] A new multidimensional array indexing intrinsic

We could also simply extend the existing inrange mechanism to non-constantexpr GEPs.  It would remove an inconsistency in the semantics, be relatively straight forward, and solve the motivating example. (I didn't read the proposal in full, so there may be other examples it doesn't solve.) Philip On 7/22/19 10:01 AM, Peter Collingbourne via llvm-dev wrote: > The restrictions of

> It seems that the main advantage of your proposal is that it would allow for non-constant strides (i.e. variable length arrays) in dimensions other than the first one. Do these appear frequently enough in the programs that you're interested in to be worth optimizing for? Yes - at least in Chapel (which is one of the motivating languages) these are very common. In other words, typical

It's also very common in Fortran. -David Michael Ferguson via llvm-dev <llvm-dev at lists.llvm.org> writes: >> It seems that the main advantage of your proposal is that it would >> allow for non-constant strides (i.e. variable length arrays) in >> dimensions other than the first one. Do these appear frequently >> enough in the programs

Intrinsics can return `llvm_any_ty` (Intrinsics.td). In that case the return type is added as a suffix to the intrinsic's name, i.e. the syntax in the RFC is not 100% the syntax for intrinsics. Same for the parameters which each must have their types explicitly mentioned. Michael Am Mo., 22. Juli 2019 um 19:08 Uhr schrieb Kaylor, Andrew <andrew.kaylor at intel.com>: > > Is it

Hi, I think I understand what the problem is. The return type will also be an untyped pointer, just like GEP. However, GEP needs to know what the size of one element is. Like it is now with overloadable intrinsics, we might derive it from the suffix. Another solution is that we pass the element and array sizes in bytes, instead of multiples of the element size. As a third options, we might change

Am Mo., 22. Juli 2019 um 10:50 Uhr schrieb Doerfert, Johannes <jdoerfert at anl.gov>: > Why introduce a new intrinsic (family)? It seems that would require us > to support GEPs and GEP + "multi-dim" semantics in various places. What is > the benefit over a GEP extension? Adding an intrinsic is easier than adding or extending an existing instruction, as suggested by

hi there, trying to follow the steps of Yan & Rossini 2003, I have two problems : first when I 'make CrossCompileBuild', I get : ****************************************************************************** make[1]: Entering directory `/home/ros/RWORK/CROSSSOMP/WinR/R-1.8.0/src/gnuwin32' make -f Makefile.docfiles make[2]: Entering directory

After having spoken to Johannes, I think we had a classic misunderstanding on what "extending" means. 1. The most obvious why for me was changing GEP to allow variable-sized multi-dimensional arrays in the first argument, such as %1 = getelementptr double, double* %ptr, inrange i64 %i, inrange i64 %j (normally GEP would only allow a single index argument for a pointer-typed base

Can someone explain why I am getting the following error: in the r code below? Error in solve.default(diag(2) + ((1/currvar) * (XX1 %*% t(XX1)))) : system is computationally singular: reciprocal condition number = 0 In addition: There were 50 or more warnings (use warnings() to see the first 50) The R code is part of a bigger program. ##sample from full conditional

Hello. I have a 4 dimensional array and I want to fill in the slots with values which are a function of the inputs. Through searching the forums here I found that the function "outer" is helpful for 2x2 matrices but cannot be applied to general multidimensional arrays. Is there anything which can achieve, more efficiently than the following code, the job I want? K <-

Am Di., 23. Juli 2019 um 17:16 Uhr schrieb Kaylor, Andrew <andrew.kaylor at intel.com>: > Do we really have code that uses the suffix of an intrinsic for semantic information? That seems like a bad idea. My understanding was that the suffix was just there to provide a unique name and the function signature took care of everything else. I agree that this is also not my preferred option,

Hi, I am new in R and stumbled on a problem my (more experienced) friends can not help with with. Why isnt this code working? The function is working, also with the loop and the graph appears, only when I build another loop around it (for different values of p) , R stays in a loop? Can't it take more then 2 loops in one program? powerb<-function(x,sp2,a,b,b1,m) {

Dear list, I have the function (as a simple example, which is actually part of a larger function) pres.test<-function(N0=N0, N1=N1) { dt<-5 r<-log(N1/N0)/dt r } which calculates the annual growth rates in a population Where N0 is the population classified into age intervals, say 5 years, at time=1995, and N1 is the population by 5 year age classes at time=2000.

Hello, I've the following list n: > n [[1]] [1] "NEW" "OLD" "PRG" [[2]] [1] "04h" "24h" [[3]] [1] "000mM" "010mM" "025mM" "050mM" "100mM" where n <- dimnames(some.multidim.array) I'm trying to define a generic function that generates meaningful names from this list, e.g.

Hi all, On Wed, 24 Jul 2019 at 16:14, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Mmmh, looks like Tim Northover is actively working on typeless/opaque > pointers, e.g. https://reviews.llvm.org/D64203 Yep, I'm spending as much time as I can on the project. I think there's not really much chance that it'll be required in this cycle (i.e. when we fork

I've got a covariance matrix that I'd like to index using the dimnames: > vcov1 n0 x0 s n1 n2 n0 82.43824759 1.839505e-02 -4.975196e-01 2.882394e+03 -2.615986e-01 x0 0.01839505 6.134010e-03 -7.695922e-04 -6.373946e+01 6.086321e-03 s -0.49751964 -7.695922e-04 9.638943e-03 3.406594e+02 -3.173671e-02 n1 2882.39407745

Hi All, Apologies for the simplicity of my question, but I would be grateful for any advice. Thanks I'm trying to put the output from a for loop into a data frame, however I have not been successful. The steps I have taken are: *R-code:* >for (k in 1:(nt-1-n0) ){ > n<- n0-1+k > lam=n/nt > Q=x[n] > output1<-data.frame(cbind(k,n,lam,Q)) > output1 > }

Hi Craig, On 03.07.19 17:33, Craig Topper wrote: > Don't the CreateICmp calls return a Value* with an i1 type? But then > they are added to an i8 type? Not sure that works.  I had that initially: auto cf = IRB.CreateICmpULT(Incr, ConstantInt::get(Int8Ty, 1)); auto carry = IRB.CreateZExt(cf, Int8Ty); Incr = IRB.CreateAdd(Incr, carry); it makes no difference to the generated assembly

Currently tablegen emits a rather surprising match code for the following case: Suppose we have a pattern that uses a ComplexPattern to match an operand. This pattern then appears as a child pattern in a different pattern. Pattern 1: (N1 ComplexPattern:OP) Pattern 0: (N0 (N1 ComplexPattern:OP)) The match code for ComplexPattern is passed in N1 in Pattern 1 and N0 in Pattern 0. This means

On Jul 25, 2019, at 7:20 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Am Mi., 24. Juli 2019 um 16:13 Uhr schrieb Tim Northover > <t.p.northover at gmail.com>: … Siddharth’s original RFC <https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md> ... >> Apart from all that, I'm pretty disappointed to see this as an