search for: bitcodefil

...; initializeAnalysis(Registry); initializeCodeGen(Registry); initializeTarget(Registry); LLVMContext &Context = getGlobalContext(); // Read in the bitcode file... std::string ErrorMessage; OwningPtr<MemoryBuffer> Buffer; error_code ec; Module *M = 0; char BitcodeFile[100]; FILE* fp=fopen("profile.ini","r"); if(fp) fscanf(fp,"%s\n",BitcodeFile); if (!(ec = MemoryBuffer::getFileOrSTDIN(BitcodeFile, Buffer))) { M = ParseBitcodeFile(Buffer.get(), Context, &ErrorMessage); } ProfileInfoLoader PIL("...

...ence. It seems that when bugpoint is run with --run-jit, the linker args are not passed to gcc (from tools/bugpoint/ExecutionDriver.cpp) : if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, OutputFile, AdditionalLinkerArgs, SharedObjs, Timeout, MemoryLimit); else RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, OutputFile, std::vector<std...

...rst link bitcodes like llvm-link, appending @myvar's from both modules into a single one, then run my pass, and only then perform linking at object level. However, LLD complains about duplicated symbol "myvar" and doesn't even run any passes. I've tracked the problem down to BitcodeFile::parse() function from https://github.com/llvm/llvm-project/blob/master/lld/COFF/InputFiles.cpp#L918 - it doesn't take linkage type into account. Can anything be done about this problem? Or was my approach broken from the beginning? Thanks in advance. -------------- next part --------------...

...is run with > --run-jit, the linker args are not passed to gcc (from > tools/bugpoint/ExecutionDriver.cpp) : > > if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || > InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, > OutputFile, AdditionalLinkerArgs, > SharedObjs, > Timeout, MemoryLimit); > > else > > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, >...

...seem to be doing so. > > Does anyone know what I should be doing? > Looking at the LLVM 2.5 version, it prints out the count of the number of instructions as part of its statistics. To run it on a bitcode file, you should be able to do the following: opt -stats -analyze -instcount <bitcodefile> The -stats option tells opt to print statistics collected by each pass. The -analyze option tells opt that it is only doing analysis and not any transformation. The -instcount is the command line option to run the code in InstCount.cpp (notice the RegisterPass line in the source code; this...

Hello, I'm trying to print the instruction count of a bytecode file using the 2.4 release of LLVM. I found llvm-2.4/lib/Analysis/Instcount.cpp but I'm not sure what to do with it. I also looked at llvm-bcanalyzer. The documentation says this command is supposed to print the instruction count in the summary, but it doesn't seem to be doing so. Does anyone know what I should be

...run > with --run-jit, the linker args are not passed to gcc (from tools/ > bugpoint/ExecutionDriver.cpp) : > > if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || > InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, > OutputFile, AdditionalLinkerArgs, > SharedObjs, > Timeout, MemoryLimit); > > else > > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, >...

...t, the linker args are not passed to gcc (from >> tools/bugpoint/ExecutionDriver.cpp) : >> >> if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || >> InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) >> >> RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, >> OutputFile, AdditionalLinkerArgs, >> SharedObjs, >> Timeout, MemoryLimit); >> >> else >> >> >> RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, In...

On Tue, Oct 28, 2008 at 12:17 PM, Prakash Prabhu <prakash.prabhu at gmail.com> wrote: > Generating reference output from raw program: <cbe><gcc> > Error running tool: [snip] > /tmp/cc08IpX8.o: In function `SyLoadModule': > bugpoint-test-program.bc.cbe.c:(.text+0x25705): undefined reference to > `dlopen' [snip] This is saying that compilation with CBE is

...p > +++ b/lld/COFF/Driver.cpp > @@ -72,6 +72,9 @@ bool link(ArrayRef<const char *> Args, bool CanExitEarly, > raw_ostream &Diag) { > exitLld(errorCount() ? 1 : 0); > > freeArena(); > + ObjFile::Instances.clear(); > + ImportFile::Instances.clear(); > + BitcodeFile::Instances.clear(); > return !errorCount(); > } > > I don't know how to make a test for this, since it depends on running LLD > twice in the same process. > > Can I get some assistance trying to get this fix upstreamed? > > On Wed, Jul 25, 2018 at 2:18 AM, Andrew...

Hi, I have a program that runs when statically compiled using llc and gcc but crashes with a segmentation fault when run with lli. I am trying to debug it with bugpoint and the initial part of bugpoint seems to be suggesting that I am somehow missing the linking with the libraries having dlsym/dlopen although I am passing it to lli : *$ bugpoint -run-jit

...attachment was scrubbed... Name: TestModule.asm Type: application/octet-stream Size: 4623 bytes Desc: TestModule.asm URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/cffe649d/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: BitCodeFile.bc Type: application/octet-stream Size: 6936 bytes Desc: BitCodeFile.bc URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/cffe649d/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectFile.obj Type: application/octet...

...ere an api and tool whereby I can compile a llvm plugin or utility that will load a bitcode, transform it to the appropriate data structures and LLVM IR, and feed that IR to my plugin or utility according to some traversal or simple brute space by command line? As in: load-bitcode ./myplugin.so -- bitcodefile.bitcode Is there an easy way to perform constant folding on a given LLVM IR SSA value? Is there an existing data structure that allows storing LLVM IR in a Set or Map type? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-de...

If you call lld::coff::link twice, the second time gives this backtrace: msvcp140d.dll!00007ffc35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const *

...mpiles bitcode files into real object files. // @@ -1798,6 +1803,11 @@ template <class ELFT> void LinkerDriver::link(opt::InputArgList &Args) { if (errorCount()) return; + // LTO may have introduced new common symbols, so convert them + // to regular defined symbols. + if (!BitcodeFiles.empty()) + replaceCommonSymbols(); // If -thinlto-index-only is given, we should create only "index // files" and not object files. Index file creation is already done // in addCombinedLTOObject, so we are done if that's the case. @@ -1879,7 +1889,6 @@ template <class...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

Thanks for the info Teresa, Regards M Suresh From: Teresa Johnson <tejohnson at google.com> Sent: Thursday, June 20, 2019 7:15 PM To: Mani, Suresh <Suresh.Mani at amd.com> Cc: Rui Ueyama <ruiu at google.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Expected behavior of lld during LTO for global symbols (Attr Internal/Common) [CAUTION: External