similar to: [LLVMdev] Discrepancies in LLVM sources

On Sat, Sep 17, 2011 at 9:14 PM, Yuri <yuri at rawbw.com> wrote: > Looks like constants in include/llvm-c/Core.h aren't in sync with enums. > For example, LLVMAdd is 8 in Core.h and  llvm::Instruction::LLVMAdd > evaluates to 9 in C++. > Same for Cast Operators section and possibly in other places. Yes; we don't make any sort of guarantee about that, and such a guarantee

On 09/17/2011 21:53, Eli Friedman wrote: > Yes; we don't make any sort of guarantee about that, and such a > guarantee is not necessary for correctness. Aren't values in Core.h supposed to be used by users of API and they should match enums, or what they are for then? What are they matched against? >> > Also, llvm/Support/TargetRegistry.h and

Hi all, I am emitting code for assembler which wants non-standard text for labels (not just "LABEL:"). One way would be to override all methods of AsmPrinter which call MCStreamer::EmitLabel but this is too painful. I can think of two solutions: 1) add AsmPrinter::EmitLabel which calls Streamer by default but may be overriden in target AsmPrinters 2) Register my own instance of

This is from https://stackoverflow.com/questions/48360685/no-targets-in-targetregistry I have the following code, which should get the default llvm::Target. auto const targetTriple = llvm::sys::getDefaultTargetTriple(); llvm_module.setTargetTriple(targetTriple); std::string error; auto const * target = llvm::TargetRegistry::lookupTarget(targetTriple, error); if (target ==

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst));

Hi! is there a way to get the c backend using llvm::TargetRegistry::lookupTarget()? e.g. llvm::TargetRegistry::lookupTarget("c", error)? - Jochen

On Sep 18, 2010, at 8:14 AM, Yuri Gribov wrote: > Hi all, > > I am emitting code for assembler which wants non-standard text for > labels (not just "LABEL:"). One way would be to override all methods > of AsmPrinter which call MCStreamer::EmitLabel but this is too > painful. I can think of two solutions: > > 1) add AsmPrinter::EmitLabel which calls Streamer by

On 10/02/2012 13:01, Duncan Sands wrote: > > I think Chris is the right person to look at this, hopefully he will. Now 5 months passed. I updated the patch for this current revision. Can anybody review this and check in please? http://llvm.org/bugs/show_bug.cgi?id=13163 Yuri

In r134967 it still worked, and in r137742 it now doesn't. I used such flags: --enable-assertions --enable-shared --enable-libffi --enable-debug-runtime --enable-debug-symbols --disable-optimized Before build would create directory tools/llvm-shlib under the build tree. Now it is missing. Yuri

This function (understandably) takes quite a long time, because it has to go through each function in module and write its binary. But it probably can be parallelized if different threads would write binaries separately, and then merge them together. Is this implemented or planned? Yuri

It worked in August. Last time I’ve asked (again, in August) someone did seem to care, but it is inevitable it would bitrot if it’s not built in any of the bots. George > On May 4, 2018, at 2:53 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > While playing with sanitizer in a downstream project, I found out this. > >

On 02/02/2014 01:48, David Chisnall wrote: > In most calling conventions, this is a callee-save register. After its last use, the register allocator may reuse that register. On x86 and ARM, the register that contains this is also (usually) the register used for But the rule "after the last use, the register allocator may reuse it" is also introduced by llvm, since register

Hi, The code @ line 584 of TargetRegistry.h effectively suppresses specifying any AsmStreamer constructor function but stock createAsmStreamer one. Is it by intention or condition should be replaced with != ? Best regards, Max

How can I copy the value from another BB? PHI instruction with one argument would fit, but it requires that all arguments are in immediately preceding BBs. Yuri

I did these steps: * checked out llvm trunk, and clang trunk * created symbolic link llvm/tools/clang * created separate folder: llvm-objects * run configure and gmake in llvm-objects It builds ok until it hits clang, at which point I get an this error: gmake[2]: Entering directory `/tmp/llvm-svn/llvm-objects/tools/clang' Makefile:44: Makefile.config: No such file or directory Makefile:127:

On Thu, Feb 20, 2014 at 1:58 PM, Yuri <yuri at rawbw.com> wrote: > On 02/18/2014 00:44, 杨勇勇 wrote: > >> I ported llvm backend and lldb recently. Both tools can basically work. >> lldb is able to debug programs in asm style and frame unwinding is OK. >> >> But "frame variable XX" does not work because lldb is not able to >> determine >> the

Thank you. I went ahead with a speculative fix in r331568. I'm not familiar _at all_ with the tool, so, although the fix was straightforward, another pair of eyes from somebody familiar with the tool would be appreciated. On Fri, May 4, 2018 at 5:10 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > It worked in August. > Last time I’ve asked (again, in August) someone did

I think my patch fell through the cracks: http://llvm.org/bugs/show_bug.cgi?id=13163 Could anybody please check it in? Thanks, Yuri

On 02/19/2011 14:52, Yuri wrote: > Will MC path for JNI be included in 2.9? > Sorry. I meant: Will MC path for JIT be included in 2.9?

On Feb 19, 2011, at 8:05 PM, Yuri wrote: > On 02/19/2011 14:52, Yuri wrote: >> Will MC path for JNI be included in 2.9? >> > > Sorry. I meant: Will MC path for JIT be included in 2.9? While it would be nice, it doesn't seem like anyone is working on it at the moment. -Chris