similar to: Can a Constant have more than one use?

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

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

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, 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

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?

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:

Hello all, This is a general question regarding type conversion: from: <ty>** to: [<size> x <ty>]* >From what I understand, bitcast is wrong in this case because a GEP into a <ty>** should be computed differently from a GEP into [<size> x <ty>]*. So, what is the correct way to perform this type conversion? Thanks, Siddharth -- Sending this from my

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>]* >

Hi all, I am newbie for llvm. I just create a global variable, there are some statements in my pass like: LoadInst* int64_64 = new LoadInst(pthreadPID, "", false, OptAplusOne); int64_64->setAlignment(8); int64_64->dump(); LoadInst* int32_65 = new LoadInst(gvar_int32_myFlag, "", false, OptAplusOne); int32_65->setAlignment(4);

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)

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

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

Hello, I'm implementing a custom Haskell-to-LLVM compiler, and in my experimentation, noticed that GHC is much slower than clang certain examples, such as the ackermann function. However, from reading their respective IRs (Cmm for GHC and LLVM for clang), I don't really see much of a difference. Here is a link to the numbers. (n, m) are the parameters to the ackermann function

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

On Tue, Dec 19, 2017 at 9:10 AM, Siddharth Bhat via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I could be entirely wrong, but from my understanding of memorySSA, each > def defines an "abstract heap state" which has the coarsest possible > definition - any write will be modelled as a "new heap state". > This is true for def-def relationships, but

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

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.

As the question asks, I'm having some trouble using initializeAllTargets(). I have a CMakeLists that uses: llvm_map_components_to_libnames(LLVM_LIBS ... AllTargetsAsmParsers AllTargetsAsmPrinters AllTargetsDescs AllTargetsInfos ...) However, even with these, when I try to compile my program, I get linker errors: CMakeFiles/sxhc.dir/src/main.cpp.o: In function

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

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,