similar to: [LLVMdev] llvm::ConvertibleToGEP

But it's completely empty, no? const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, std::vector<Value*> &Indices, const TargetData &TD, BasicBlock::iterator *BI) { return 0; } in lib/Transforms/TransformInternals.cpp, how can this be? Naftali On Tue,

I'm sorry, it had seemed to me that the documented functionality: // ConvertibleToGEP - This function returns true if the specified value V is // a valid index into a pointer of type Ty. If it is valid, Idx is filled in // with the values that would be appropriate to make this a getelementptr // instruction. The type returned is the root type that the GEP would point to would be quite

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > But it's completely empty, no? > > const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, > std::vector<Value*> &Indices, > const TargetData &TD, > BasicBlock::iterator *BI) { > return 0; > }

Well, I guess I was hoping soemthing like this would help in the pointer-to-array transformation for the following code: > > int A[100], B[100], C[100], X, Y, Z; > > > > int *p_a = &A[0]; > > int *p_b = &B[0]; > > int *p_c = &C[0]; > > > > int i, j, k, f; > > for ( k = 0; k < Z; k++ ) > >

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > I'm sorry, it had seemed to me that the documented functionality: > > // ConvertibleToGEP - This function returns true if the specified value V is > // a valid index into a pointer of type Ty. If it is valid, Idx is filled in > // with the values that would be appropriate to make this a getelementptr > // instruction. The type

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > It seems like general dependence analysis in LLVM should require that this > function be, well, functional. Is it simply a placeholder waiting for > someone to come and fill in the details? It also appears that some other > things besides dependence analysis depend on it as well...anyone working on > this? I don't understand

Hi, everyone. I've been examining llvm for a while and been duly impressed. I'd like to contribute in the area of dependence analysis, and a good place to start seems to be in the transformation of pointers to explicit array accesses. Is anyone else working on this? If not, does this seem a plausible place to start and how would be the best way to go about it? Thanks, Naftali

On Thu, 21 Jul 2005, Naftali Schwartz wrote: >> If you're interested in dependence analysis, the next important step is > to >> start analyzing distance and direction vectors. > > Well, specifically, I was thinking of a mechanism to turn this: The indvars pass is *intentionally* restricted to only promoting affine expressions to array subscripts, not arbitrary

> LLVM already includes this: the -indvars pass. It turns things like this: > > int *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. Well, specifically, I was thinking of a

OK, thanks Chris, I've found that running opt -loopsimplify -instcombine -indvars -stats gives me the setup I need for this transformation, and a small patch makes it happen in the simple case we discussed. However, I'm having some trouble when things get a bit more complicated with 3 nesting levels: int A[3000000], B[20000], C[100], Z; int main() { int i, j, k, *a, *b,

On Thu, 28 Jul 2005, Naftali Schwartz wrote: > I now understand that IndVarSimplify.cpp is capable of reproducing array > references when the pointer initialization from the array address is found > inside the immediately enclosing loop, such that in the following code: Ok. > int A[20000], B[100], Z; > int main() > { > int i, j, *a, *b; > for ( a =

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++

Hello, I use the SayNumber() with variable. for example the number 1234 - asterisk play the number without and. -- Executing [888 at from-internal:1] Set("SIP/103-0000035d", "LANGUAGE=en") in new stack -- Executing [888 at from-internal:2] SayNumber("SIP/103-0000035d", "1234") in new stack -- <SIP/103-0000035d> Playing

This may sound like a dumb question but for those who do not follow either :- "why do you want to turn pointers into indexes ?" Aaron

On Mon, 18 Jul 2005, Naftali Schwartz wrote: > Hi, everyone. I've been examining llvm for a while and been duly impressed. > I'd like to contribute in the area of dependence analysis, and a good place > to start seems to be in the transformation of pointers to explicit array > accesses. Is anyone else working on this? If not, does this seem a > plausible place to

> LLVM already includes this: the -indvars pass. It turns things like this: > > int *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. You can check out

Hello, Following up on last week's LLVM-Dev meeting where we discussed MemorySSA related topics, I created the following google doc <https://docs.google.com/document/d/1-uEEZfmRdPThZlctOq9eXlmUaSSAAi8oKxhrPY_lpjk/edit#> with some of the meeting notes and planning for future meetings. For those who participated, please feel free to add items I may have missed into the document and cc

Many thanks to Henrik for remembering the report in Bugzilla and to Kurt for implementing the change and finding out the true number of affected packages. On Wed, 22 Jan 2025 15:34:41 -0500 Ian Farm <ian.farm at maine.edu> wrote: > Would packages using the underscore placeholder with the native pipe > need to also depend on R >= 4.2.0? That's a good find! For the R >= 4.2

>>>>> Ivan Krylov via R-devel writes: Thanks. I am already looking handling the 4.2.0 placeholder syntax, but likely will need to refactor the code I added yesterday. The "experimental" 4.3.0 extra placeholder feature looks like a lot of effort: ideally there would be a simpler way. I'll ask on R Core. My guess would be that the new syntax is particularly

On 21/04/2023 12:16 p.m., Michael Milton wrote: > I'm afraid I don't understand. I know that parsing `+`(1, 1) returns a > result equivalent to `1?+ 1`, but why does that impose a restriction on > parsing the pipe operator? What is the downside of allowing arbitrary > RHS functions? I thought the decision to exclude "_ + 1" happens after enough parsing has