similar to: Converting i32** to [4 x i32]* ?

What would the "correct form of GEP be"? Thanks, Siddharth On Fri 11 Aug, 2017, 23:47 Krzysztof Parzyszek via llvm-dev, < llvm-dev at lists.llvm.org> wrote: > On 8/11/2017 3:40 PM, Siddharth Bhat via llvm-dev wrote: > > > > This is a general question regarding type conversion: > > > > from: <ty>** > > to: [<size> x <ty>]* >

Hello, Calling `replaceUsesOfWith` with a value in a different addrspace does not keep the addrspace of a GEP consistent. Is this known? Is this a bug or expected behaviour? Minimal counterexample link <https://gist.github.com/bollu/152ba5e1c20c03c7fc6d8c7b23ba828f> Reproduced here: #include <iostream> #include "llvm/ADT/APFloat.h" #include

The GEP constructor does not assert that the source and destination types match. Of course, this is incorrect and causes random failures somewhere down the line. Could I add general sanity checks to the GEP constructor? In general, is an Instruction allowed to be in an inconsistent state? If so, is there some well known method to "verify" whether an instruction is consistent or not?

On 05/30/2018 06:04 AM, Siddharth Bhat via llvm-dev wrote: > You can run SCEV which will see through bitcasts and GEPs, so it > should give an expression of the form (base + offset) on the pointer > of the load. Specifically, you can use ScalarEvolution to subtract the expression for the base descriptor from the expression for the loaded pointer and see if the result is a SCEVConstant.

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

Hello, We would like to begin discussions around a new set of intrinsics, to better express multi-dimensional array indexing within LLVM. The motivations and a possible design are sketched out below. Rendered RFC link here <https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md> Raw markdown: # Introducing a new multidimensional array indexing intrinsic ## The

I see. Is there a pre-existing way to do this in LLVM? Cheers, ~Siddharth. On Thu, 17 Aug 2017 at 02:12 Craig Topper <craig.topper at gmail.com> wrote: > ConstantExprs are immutable, they can't be changed once they are created. > And a ConstantExpr can reference other ConstantExprs. So replacing all uses > of a Value in a ConstantExpr would require creating a new immutable

You can run SCEV which will see through bitcasts and GEPs, so it should give an expression of the form (base + offset) on the pointer of the load. Cheers siddharth On Wed 30 May, 2018, 16:30 Venkataramanan Kumar via llvm-dev, < llvm-dev at lists.llvm.org> wrote: > Hi, > > Below is the snippet of LLVM IR code generated by Flang > > ---snip-- > %3 = getelementptr i64,

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

Whoops, sorry, I meant "value->replaceAllUsesWith". Should I create a new post with an updated title? Thanks Siddharth On Thu 17 Aug, 2017, 01:05 Tim Northover <t.p.northover at gmail.com> wrote: > On 16 August 2017 at 15:39, (IIIT) Siddharth Bhat via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > From what I have observed, using

Hi, Below is the snippet of LLVM IR code generated by Flang ---snip-- %3 = getelementptr i64, i64* %"a$sd", i64 11, !dbg !16 %4 = bitcast i64* %3 to i32*, !dbg !16 %5 = load i32, i32* %4, align 4, !dbg !16, !tbaa !22 ---snip-- My requirement is for any such LoadInst (example: %5), I want to check if its base GEP (i.e. %3) loads at particular offset (11) from its corresponding

Hello all, I recently felt the need to have debug info at the LLVM IR level (because my frontend's semantics vastly differ from IR that it doesn't make much sense to use it). Asm can sometimes be too "low level", so it's nice to have the ability to single-step at the IR level. The pass that used to do this (-debugir) bitrotted and was removed from tree. I spent the weekend

Hello all, >From what I have observed, using `Inst->replaceAllUsesWith` does not replace uses of the `Inst` in `ConstantExpr`s. Is there some way to have a universal replaceAllUsesWith? Thanks, ~Siddharth. -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'd be interested in attending and helping organise the Hyderabad meetup. Cheers Siddharth On Wed 30 May, 2018, 14:32 Siddharth Shankar Swain via llvm-dev, < llvm-dev at lists.llvm.org> wrote: > Hi Folks, > > We are a group of LLVM compiler developers in Hyderabad area. Considering > few previous mail about meetups in India, we are planning to organize LLVM > meetups

As the question asks. IIRC, I have only seen constants use to: 1. setup globals 2. as "constant parameters" to instructions. In both these cases, from what I understand, they will have a single use. Is it possible to create a Constant with multiple use(r)s? Thanks, Siddharth -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML

Hello all, I've seen some discussion that InstCombine is "too general" and that llvm should implement a proper graph rewrite mechanism: Link to llvm-dev discussion about this: http://lists.llvm.org/pipermail/llvm-dev/2017-May/113219.html, Link to review where this came up (and I first heard about it): https://reviews.llvm.org/D37195. I wanted to understand what the current issues

Hi Folks, We are a group of LLVM compiler developers in Hyderabad area. Considering few previous mail about meetups in India, we are planning to organize LLVM meetups in India evry monthly or bimonthly in the best interest of other developers. Based on the concentration of developers Pune, Bangalore and Hyderabad are the location we have in mind. Interested folks please reply stating ur

Hello all, I have a custom allocator, and would like to teach LLVM about its semantics. In particular, I would like LLVM to kill allocations that are "dead", similar to dead new in C++. Consider this example: ; ModuleID = '<stdin>' source_filename = "Module" ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare i8* @alloc(i64)

I looked around for the status of OrcJIT FFI support. The last e-mail thread I could find was this one: Link <http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html> Raw: http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html Is OrcJIT now considered stable enough that there can be "official" exposed C APIs? If not, what's the standard approach if I