similar to: plugin-opt=save-temps doesn't work in LLVM Gold 5.0.0

Hi I use the LDFLAGS=" -flto -fuse-ld=gold -Wl,-plugin-opt=save-temps " to generate the makefile and to make the whole program. However, found four different kinds of bitcode for each target. For example, I am compiling coreutils. For the program "nohup", I can get nohup.0.0.preopt.bc nohup.0.2.internalize.bc nohup.0.4.opt.bc nohup.0.5.precodegen.bc If I am right, I

These are the bitcode at different stages of the LTO portion of the compile. LTO merges the IR for all files being linked and optimizes them as a single monolithic module. The preopt.bc is the merged IR just after merging and before performing any LTO optimizations. internalize.bc is after performing whole program internalization. opt.bc is after the optimization pipeline, and .precodegen.bc is

Hi Teresa Thanks for your very quick and clear explanation. I have one more question. The emit-llvm option will give you the IR for a single source file when you compile it with -c. All of those files when combined give the IR in the preopt.bc temp file. =========== So if I use "clang -emit-llvm -c" to generate the .ll file. It should be the same as the one I generated by using

Hi Muhui, I tried to grep the "DW_TAG_subprogram" from the debug_info . However, I noticed that the number I found is still less than the whole functions I found with LLVM IR. Do you have any experiences? Many Thanks The only explanation that comes to mind, is that the functions are not in the final binary object file. However, previously you said you believed they were present. If

On Mon, Jan 28, 2019 at 8:16 AM Tim Northover <t.p.northover at gmail.com> wrote: > > On Mon, 28 Jan 2019 at 14:10, Peng Yu via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > ld: unknown option: -plugin-opt=save-temps > > The macOS linker supports -save-temps directly (but not -plugin-opt). > I haven't tried, but I'd guess that if you modified the

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? `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

My pass complains and gives up after spitting out: ====================================== Instruction does not dominate all 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? --

On 11 June 2017 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: >

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 what the sub-type is, how can I further use this object? I tried something like this: ================================================= Value* value = store_inst->getValueOperand()

I am using pre-built LLVM/Clang 3.8.0 binaries on Ubuntu 16.04.2, 64 bit. I tried to lift a minimal program to LLVM IR, then link the IR to DataFlowSanitizer libraries to produce executable code. In the second step, the process throws a bunch of linker errors. ========================================= #include <sanitizer/dfsan_interface.h> #include <assert.h> int main(void) { int

I am writing an analysis pass on LLVM which requires to: [1] generate unique, positive ID corresponding to each instruction [2] the ID must survive across runs [3] given the ID, corresponding instruction has to be mapped back For [1], the general suggestion is to use the Value* instr_ptr associated to each instruction. The instr_ptr points to specific instruction in memory, hence

> On macOS you just omit the '-fuse-ld=gold' and it will work out of the box. > > ./configure CC=clang RANLIB=llvm-ranlib CFLAGS=-flto > > LDFLAGS=-Wl\,-plugin-opt=save-temps\ -flto\ -fuse-ld=gold > > make No. It doesn't work on Mac OS by just omitting '-fuse-ld=gold'. $ ../../../extract/bash-5.0/configure CC=clang CXX=clang++ RANLIB=llvm-ranlib

I am wriitng an LLVM pass to insert instrumentation at certain points 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

On 11 June 2017 at 14:04, don hinton <hintonda at gmail.com> wrote: > Assuming you know it's a 64 bit 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,

On 11 June 2017 at 23:06, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast- > templates > I understand isa and dyn-cast let you test the type of an object at run-time by leveraging LLVM's custom implementation of RTTI. However, it doesn't make much sense to test out for all possible sub-classes to

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* vo = store_inst->getValueOperand(); uint64 value = /* cast vo to unsigned int 64 bit */ func(value); } How can I force

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>

I tried the following: - 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...

I am learning to write LLVM pass by trying to reproduce [hello world][1] example. The pass `hello.cpp` looks like: #include "llvm/Pass.h" #include "llvm/IR/Function.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; namespace { struct Hello : public FunctionPass { static char ID; Hello() : FunctionPass(ID) {}