similar to: [LLVMdev] AsmPrinter::EmitLinkage

On May 10, 2010, at 6:46 PM, Nathan Jeffords wrote: > I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF). > Would it make sense to delegate the implementation to a specialized object from current the object

On Mon, May 10, 2010 at 9:43 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 10, 2010, at 6:46 PM, Nathan Jeffords wrote: > > > I have been looking over AsmPrinter::EmitLinkage (around line 195 of > lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation > will vary quite a bit depending on what object file format is in use (MachO, >

Hi everyone, I am in the process of adding some new code for th ARM/MC ELF emission, but noticed a curious linkage between th AsmPrinter and the MC. It looks like the MC code (on X86 at least) calls out to the (misnamed?) AsmPrinter to dump out ELF bits (in X86AsmPrinter.cpp) in the same routine, using conditional branching.... As JimG and I are working both on ARM emission stuff, I want to

I noticed that AsmPrinter::EmitLinkage doesn't handle ExternalWeakLinkage. Is that an oversight or is something deeper going on? -Dave

On Jul 12, 2010, at 5:27 PM, David Greene wrote: > I noticed that AsmPrinter::EmitLinkage doesn't handle > ExternalWeakLinkage. Is that an oversight or is something > deeper going on? EmitLinkage is never called on external globals. -Chris

> I think it emits valid output, but I don't think it handles weak symbols > correctly, as COFF supports true weak symbols, but this code appears to turn > them into a linkonce section which is not quite the same thing. Yes. This was intentional, since: 1. At the time of writing the code binutils did not support weak stuff 2. It was my feeling, that weak (especially external weak

> For the windows sub-target is it safe to assume Microsoft's linker is the being targeted? I'd really appreciate if both ms link and gnu ld will be tested, if this is possible. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 11 May 2010 18:04, Anton Korobeynikov <anton at korobeynikov.info> wrote: > > For the windows sub-target is it safe to assume Microsoft's linker is the > being targeted? > I'd really appreciate if both ms link and gnu ld will be tested, if > this is possible. I have done some tests with Cygwin, and most things seem okay, e.g. Static Constructors...Virtual

On Tue, May 11, 2010 at 10:49 AM, Aaron Gray < aaronngray.lists at googlemail.com> wrote: > On 11 May 2010 18:04, Anton Korobeynikov <anton at korobeynikov.info> wrote: > >> > For the windows sub-target is it safe to assume Microsoft's linker is >> the being targeted? >> I'd really appreciate if both ms link and gnu ld will be tested, if >>

On Tue, May 11, 2010 at 2:03 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > > I think it emits valid output, but I don't think it handles weak symbols > > correctly, as COFF supports true weak symbols, but this code appears to > turn > > them into a linkonce section which is not quite the same thing. > Yes. This was intentional, since: > 1. At

Hello everyone, In the file *lib/CodeGen/AsmPrinter/AsmPrinter.cpp*, I would like to obtain an MCInst corresponding to its MachineInstr. Can anyone tell me a way to do that? If that is not possible, then, I would like to know if a given MachineInstr is an *lea *instruction and I would like to know if the symbol involved with this lea instruction is a jump-table. For instance, given a

Hi, Could anyone tell me how can I turn off printing .file directive. I want to make a custom output of the filename. In AsmPrinter::doInitialization() I found: if (MAI->hasSingleParameterDotFile()) { /* Very minimal debug info. It is ignored if we emit actual debug info. If we don't, this at least helps the user find where a function came from. */ O << "\t.file\t\""

On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: > On 23/02/10 14:58, Richard Osborne wrote: >> I've recently changed the XCore target to implement BR_JT as a jump to a >> series jumps. The jump table entries are expand inline in the function >> so there is no longer a need to emit jump tables at the end of the >> function. However the emission of jump tables at

i want to emit binary code for the following implemented vector assembly instructions. P_256B_LOAD_DWORD R_0_R2048b_0, pword ptr [rip + b] P_256B_LOAD_DWORD R_0_R2048b_1, pword ptr [rip + c] P_256B_VADD R_0_R2048b_0, R_0_R2048b_1, R_0_R2048b_0 P_256B_STORE_DWORD pword ptr [rip + a], R_0_R2048b_0 I added the following lines in X86MCInstLower.cpp; unsigned NewOpc; switch (OutMI.getOpcode())

Hi, I'm gettign an assertion fail/crash in X86FrameLowering::GetFrameIndexReference when compiling the following bitcode: https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0 I tried removing the llvm.frameaddres calls but that's not it, where can I start looking for what my mistake here is? Code seems to verify just fine. ; #0 0x00e1afe8

I think r262546 introduced the assumption that allocas are used exactly once with catchpad. It seems easy to fix, though. On Mon, Oct 17, 2016 at 11:51 PM, Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This turned out to be related to reusing the local used in the catchpad, > for example given the following c++ code: > > extern void rthrow(); > > int

Hello everyone, I'm a newbie of llvm. I'm trying to insert Intel MPX instruction BNDCU with BuildMI. I add my machinefunctionpass at addPreEmitPass2. Here is the code of insertion: BuildMI(MBB, MI, DL, TII->get(X86::BNDCU64rr)).addReg(X86::BND2, RegState::Define).addReg(X86::R10); And here is to stack track when I compiler program with modified llc:

On Wednesday 17 June 2009 00:11, Evan Cheng wrote: > Asm printer. Yes, but where? I can't find it. What do I need to search for? -Dave

On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote: > On 01/03/10 21:14, Chris Lattner wrote: >> On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: >> >>> On 23/02/10 14:58, Richard Osborne wrote: >>> >>>> I've recently changed the XCore target to implement BR_JT as a jump to a >>>> series jumps. The jump table entries are

I've recently changed the XCore target to implement BR_JT as a jump to a series jumps. The jump table entries are expand inline in the function so there is no longer a need to emit jump tables at the end of the function. However the emission of jump tables at the end of a function is done inside the AsmPrinter base class and there seems to be no way of disabling this. This also seems to