search for: dipanjan

You can also `-disable-verify -o <output-filename> ` which will disable the verify check. On Sat, 21 Oct 2017 at 23:54 Dipanjan Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Yes, that definitely works. Wanted to know if there's a switch for file > output or not. > > On 21 October 2017 at 23:45, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > >> Just use Unix IO redirect? `l...

Just use Unix IO redirect? `llc -mllvm -print-after-all &> a.txt` 2017-10-22 14:17 GMT+08:00 Dipanjan Das via llvm-dev < llvm-dev at lists.llvm.org>: > > Seems like "-mllvm -print-after-all" does the trick. Is there any switch > that dumps the output to a file instead of console? > > On 21 October 2017 at 21:33, Dipanjan Das <mail.dipanjan.das at gmail.com> &gt...

...uses! %44 = icmp ne i8** %endptr, null br i1 %44, label %32, label %33 Instruction has bogus parent pointer! ====================================== Is there any way to dump the entire IR even in broken form from the backend so that I can inspect what's going on? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171021/589f7a06/attachment.html>

...7 at 07:53, David Blaikie <dblaikie at gmail.com> wrote: > Sounds like you're looking for reinterpret_cast: http://en. > cppreference.com/w/cpp/language/reinterpret_cast > I tried cast<ConstInt>(vo), but that failed at run-time. > > On Sun, Jun 11, 2017 at 3:06 AM Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> I am trying to cast a Value* irrespective of its underlying subclass to >> uint64 and pass it on to a method as an argument. >> >> if (StoreInst *store_inst = dyn_cast<StoreInst>(&I)...

...value, and the function you are calling > takes a uint64_t, try this: > The values from the test program are of type: i32/i32*/i32**. Can't I interpret these as uint64_t some way? > > Value* args[] = {store_inst->getOperand(0)}; > > > On Sun, Jun 11, 2017 at 1:16 PM, Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On 11 June 2017 at 12:05, Tim Northover <t.p.northover at gmail.com> wrote: >> >>> On 11 June 2017 at 11:56, Dipanjan Das via llvm-dev >>> <llvm-dev at lists.llvm.org&gt...

...ic memory addresses errs() << *value->getValueName(); // Doesn't compile ================================================= I have mentioned the issues in each of the cases above. I am not sure if the approach is correct or not. Please help me out. -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170611/8ad30777/attachment-0001.html>

...dfs$dfsw$dfsan_set_label': test2.bc:(.text+0x1e4): undefined reference to `dfs$dfsan_set_label' clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) ========================================= Any idea what might I be doing wrong? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170614/c95c74cd/attachment.html>

...e offset for instructions lying in lower memory region than 'main'. Even if I circumvent the problem by adding a positive bias high enough, I have no clue how can I map the instr_ptr back to corresponding IR instruction. Can anyone suggest any elegant workaround? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170504/0d96ba69/attachment.html>

...oints of the program. I want to pass the `StringRef` obtained from `getName()` as a parameter to a function `func(char* s)`. I can allocate some space on stack using `AllocaInst` to generate an `alloca` instruction. But, how can I copy the `StringRef` to the stack space? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170428/e211fe2d/attachment.html>

...plementation of RTTI. However, it doesn't make much sense to test out for all possible sub-classes to get to know what it actually is. If I just want to know sub-class a Value* is, what's the way out (other than testing with isa<>())? > > > On Mon, Jun 12, 2017 at 3:24 PM, Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> As a concrete question, I understand 'Value' class is the parent of many >> concrete sub-classes. Let's say I retrieve a Value* value = >> store_inst->getValueOperand(). Unless I know...

On 11 June 2017 at 11:32, Nikodemus Siivola <nikodemus at random-state.net> wrote: > On Sun, Jun 11, 2017 at 7:49 PM, Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On 11 June 2017 at 07:53, David Blaikie <dblaikie at gmail.com> wrote: >> >>> Sounds like you're looking for reinterpret_cast: http://en.cp >>> preference.com/w/cpp/lan...

...<StoreInst>(&I)) { Value* vo = store_inst->getValueOperand(); uint64 value = /* cast vo to unsigned int 64 bit */ func(value); } How can I force cast 'vo' to unsigned int? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170611/f2b8badf/attachment-0001.html>

Has LLVM docs deen moved to somewhere recently? The link is broken: http://llvm.org/docs/doxygen/html/classllvm_1_1InsertValueInst.html -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/64ae4f89/attachment-0001.html>

...lowing: - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(0xFFFFFFFFFFFFFFFF, 64, false)) - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(-1, 64)) I am receiving the following error: Assertion `NumBits <= MAX_INT_BITS && "bitwidth too large" failed -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171019/2e76a814/attachment.html>

On 11 June 2017 at 12:05, Tim Northover <t.p.northover at gmail.com> wrote: > On 11 June 2017 at 11:56, Dipanjan Das via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I can't pass var_value to a function accepting uint64_t. LLVM complains > > about broken function call. > > Well, yes. var_value has type "ConstantInt *", not uint64_t. Assuming > the value being...

...s Hello: main Why does my pass not get triggered for the first two functions? [1]: http://releases.llvm.org/3.8.0/docs/WritingAnLLVMPass.html#quick-start-writing-hello-world [2]: http://releases.llvm.org/3.8.0/docs/WritingAnLLVMPass.html#running-a-pass-with-opt -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170415/19c0cfb7/attachment.html>

...tion*,ID>, and use that as the analysis result. Then query that result for the ID where you need it. If you've written the analysis correctly, then you'll always get the same IDs for the same instructions given the same input IR. Jon > > --paulr > > > > *From:*its.dipanjan.das at gmail.com [mailto:its.dipanjan.das at gmail.com] > *On Behalf Of *Dipanjan Das > *Sent:* Monday, May 08, 2017 1:45 PM > *To:* Robinson, Paul > *Subject:* Re: [llvm-dev] Computing unique ID of IR instructions that > can be mapped back > > > > > > Hi Paul, >...

...ture!" If I print the types of the following: errs() << *Type::getInt64Ty(Ctx) << ", " << *var->getType(); I can see first one is i64 and second one is i64*; hence the incompatibility. How can I create an alloca variable of type i64? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171010/22cf39eb/attachment.html>

> Isn't Instruction* a pointer to the instruction in memory? If so, it'll change across runs Correct, but none of this is meant to be stored across runs, so the actual address doesn't matter. You recompute the map every time your IR is loaded. On Mon, May 8, 2017 at 7:34 PM, Dipanjan Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 8 May 2017 at 18:14, Jonathan Roelofs <jonathan at codesourcery.com> > wrote: > >> An alternative way to do it, which would be less invasive and more >> upstreaming friendly, would be to implement...

...ur of DFSan to suit my need. Therefore, I need to know how it gets integrated in the tool-chain. Initially, my idea was to insert the dfsan_set_label() calls to the IR and pass it to DFSan. However, I am not sure if it's designed to run on the source only, not on IR. -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170616/13288783/attachment.html>