search for: mcsymbolrefexpr

I have a case where I the expression (MCSymbolRefExpr) is the offset from the beginning of the section. The need is to combine that offset to the virtual address of the section it belongs, in this case .text, but it could be any section. I can get a MCSectionELF class object from MCSymbol that I get from MCSymbolRefExpr: int Kind = Value->getK...

I was mistaken as to needing the virtual address of the section , but really need to know the virtual address of the beginning of the function that contains the label whose symbol expression we have. I have a case where I the expression (MCSymbolRefExpr) is the offset from the beginning of the function. AsmPrinter::EmitJumpTableEntry() calls EmitGPRel32Value()<http://llvm.org/doxygen/classllvm_1_1MCStreamer.html#a3c0872c5c75608d870c0b6aaf0d206ed> case MachineJumpTableInfo::EK_GPRel32BlockAddress<http://llvm.org/doxygen/classllvm_1_1...

...283 of MCElfStreamer.cpp reads like this: 00283 case MCExpr::Target: llvm_unreachable("Can't handle target exprs yet!"); Does this mean that if I use a subclass of MCTargetExpr to lower MachineOperands to MCOperands, it won't work? Currently, symbol operands are lowered to MipsMCSymbolRefExpr (a subclass of MCTargetExpr) objects.

...g is sufficient, but not always. You can register a custom operand print method on complex operands via the "PrintMethod" attribute. ARM makes heavy use of this for all manner of things. -Jim On Oct 17, 2011, at 6:02 PM, Akira Hatanaka wrote: > I guess that means I should be calling MCSymbolRefExpr::Create, like > ARM does, when I lower symbol operands. Is that right? > > If MCSymbolRefExpr objects should be created, am I supposed to add > code to MCExpr::print (MCExpr.cpp:37) in order to print symbol > operands for MIps? I am hesitant to add my code here, since it looks a &gt...

...Are there more comments on the code? Thank you!! + assert(Inst.getOperand(0).isReg() && + (Inst.getOperand(ImmOp).isImm() || + (Inst.getOperand(ImmOp).isExpr() && + Inst.getOperand(ImmOp).getExpr()->getKind() == MCExpr::SymbolRef) && + static_cast<const MCSymbolRefExpr*>(Inst.getOperand(ImmOp).getExpr())->getKind() == MCSymbolRefExpr::VK_SECREL) && Just asserting "Inst.getOperand(ImmOp).isImm() || (Inst.getOperand(ImmOp).isExpr()" should be sufficient here; in theory, a wide variety of relocatable expressions are legal here, even if we do...

...reads like this: > 00283 case MCExpr::Target: llvm_unreachable("Can't handle target exprs yet!"); > > Does this mean that if I use a subclass of MCTargetExpr to lower > MachineOperands to MCOperands, it won't work? > Currently, symbol operands are lowered to MipsMCSymbolRefExpr (a > subclass of MCTargetExpr) objects. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi! I added 2 more tests and also refined an assert statement. Applies cleanly to r148473 now. Are there more comments on the code? Thank you!! Regards Kai On 01.01.2012 22:01, Eli Friedman wrote: > On Sun, Jan 1, 2012 at 10:44 AM, Kai<kai at redstar.de> wrote: >> Happy new year to all! >> >> The attached patch adds TLS support for x86_64-pc-win32 and x86-pc-win32.

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,

...le. The entry in that table is a jump to some place (may be an instruction) in a basic block. I'm reading the JumpTable code in llvm 3.5, there is a table which contains jump entries to functions. In AsmPrinter::doFinalization function from file lib/CodeGen/AsmPrinter/AsmPrinter.cpp, it gets a MCSymbolRefExpr from the function symbol. While my question is, is there a way to insert jump to place inside a basic block? Thanks! Xiaoguang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141029/91517789/attachment.htm...

...movt/movw pair (as defined in ARMInstrInfo.td) does not use EncoderMethod string to declare a special case handler. At the current time, for the assembly printing, MCAsmStreamer::EmitInstruction(const MCInst &Inst) calls out to MCExpr::print(raw_ostream &OS) which then calls out to MCSymbolRefExpr::getVariantKindName() to print the magic :lower16: and :upper16: asm tags for .s emission Currently, movt/movw emission works correctly in .s, but not in .o emission This lead me to believe that the correct place to put the code to handle MCSymbolRefExpr::VK_ARM_(HI||LO)16 for the .o path was to p...

...+const MCExpr *AArch64MachOTargetObjectFile::getTTypeGlobalReference( + const GlobalValue *GV, Mangler *Mang, MachineModuleInfo *MMI, + unsigned Encoding, MCStreamer &Streamer) const { + MCSymbol *sym = getContext().CreateTempSymbol(); + Streamer.EmitLabel(sym); + const MCExpr *expr = MCSymbolRefExpr::Create( + Mang->getSymbol(GV), MCSymbolRefExpr::VK_GOT, getContext()); + expr = MCBinaryExpr::CreateSub( + expr, + MCSymbolRefExpr::Create(sym, MCSymbolRefExpr::VK_None, getContext()), + getContext()); + return expr; +} diff --git a/lib/Target/AArch64/AArch64TargetObjectFi...

...esses (Tobias Grosser) 4. Re: How to make Polly ignore some non-affine memory accesses (Bernhard Reutner-Fischer) 5. Re: How to make Polly ignore some non-affine memory accesses (Tobias Grosser) 6. Re: How to get ELF section virtual starting address from MCSymbolRefExpr? (Rafael ?vila de Esp?ndola) 7. Re: llvm_anyint_ty clarification (Eli Friedman) 8. Automatic C++ Refactoring application. (Joe Abbey) 9. Re: Automatic C++ Refactoring application. (Chandler Carruth) 10. Re: GlobalsModRef (Jorge A. Navas) 11. Re: How to make Polly ignore some non-affine...

...nst(); llinst->setOpcode(input_opcode); llinst->addOperand(llvm::MCOperand::createReg(input_reg0)); llinst->addOperand(llvm::MCOperand::createReg(input_reg1)); const llvm::Twine tname("label_name"); const llvm::MCSymbol* mcs = Ctx.getOrCreateSymbol(tname); const llvm::MCSymbolRefExpr *msre = llvm::MCSymbolRefExpr::create(mcs, Ctx); llinst->addOperand(llvm::MCOperand::createExpr(msre)); However, while I don't get any compiler errors, and everything runs to completion without printing any errors, my output file "tmp.o" is always created, but just empty with z...

...)) { // Create a symbol for the end of function, so we can get the size as // difference between the function label and the temp label. MCSymbol *FnEndLabel = OutContext.CreateTempSymbol(); OutStreamer.EmitLabel(FnEndLabel); const MCExpr *SizeExp = MCBinaryExpr::CreateSub(MCSymbolRefExpr::Create(FnEndLabel, OutContext), MCSymbolRefExpr::Create(CurrentFnSym, OutContext), OutContext); OutStreamer.EmitELFSize(CurrentFnSym, SizeExp); } I've filed a bug for this: http://llvm.org/bugs/show_bug.cgi?id=10951 This look...

I ran into a bug in this patch. The mapping symbol produced is aligned and it should not be. Is there a way to configure the MCSymbolRefExpr such that the emitted symbol is unaligned? Alternatively, should the ARM/Thumb code be realigned after a data-in-code section? I notice that GCC leaves it unaligned. Thanks, Greg On Wed, Oct 17, 2012 at 2:32 PM, Renato Golin <rengolin at systemcall.org> wrote: > > On 17 October 2012...

On 17 October 2012 22:23, Greg Fitzgerald <garious at gmail.com> wrote: > I had to move MCELF.h to "include/llvm/MC" and added a > MCELFStreamer.h to the same directory. That okay to do? This is not a trivial question, and I'll let others chip in. Superficially, you'd think so and it might make sense in the long run, but you have to consider why it wasn't there

...t(4); auto Target = OutContext.createLinkerPrivateTempSymbol(); // Use a two-byte `jmp`. This version of JMP takes an 8-bit relative offset as // an operand (computed as an offset from the jmp instruction). OutStreamer->EmitInstruction( MCInstBuilder(X86::JMP_1) .addExpr(MCSymbolRefExpr::create(Target, OutContext)), getSubtargetInfo()); EmitNops(*OutStreamer, 9, Subtarget->is64Bit(), getSubtargetInfo()); OutStreamer->EmitLabel(Target); Which turns into: .Lxray_sled_0: .palign 2, 0x90 jmp .Ltmp0 nopw 512(%rax,%rax,1) .Ltmp0: // rest of the code Is there a...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191127/dc214059/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201911271044539_EW9BEWXX Type: application/octet-stream Size: 13168 bytes Desc: not available URL:

On Sun, Dec 4, 2011 at 9:18 AM, Kai <kai at redstar.de> wrote: > Hi! > > LLVM currently does not implement the implicit TLS model on Windows. This > model is easy: > > - a thread local variable ends up in the .tls section > - to access a thread local variable, you have to do >  (1) load pointer to thread local storage from TEB >      On x86_64, this is gs:0x58, on