search for: mcexprs

I have a question about MCExpr and its subclasses defined in MCExpr.h. I am trying to get Mips' direct object emission working. Line 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?

HI Akira, Please include the mailing list on replies. Using an MCExpr is the right way to build up things like symbol+offset. ARM has examples for that, as well, which may prove useful. For printing, the target libraries can do that however they want, including using the generic print method for expressions (or not). Often, the generic printing is sufficient, but not always. You can register a

That just means the ELF writer doesn't know yet how to deal with the target-specific data. It needs taught how to map them onto relocations and such. Do you really need to subclass MCTargetExpr? That's ordinarily only for operands that aren't representable via the normal MC stuff (for example, the ARM movw/movt relocations). You should be able represent normal symbol operands w/o

Hello, I need the expression in string. How can i convert llvm::MCExpr * to string? Please help. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/50817330/attachment.html>

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

Hi, I'd like to add support for addrspacecast in initializers of global variables, at least for the trivial case. The trivial case is if TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In this case the MCExpr for the addrspacecast is the MCExpr of its first operand. It seems hard to obtain an instance of TargetLowering in AsmPrinter::lowerConstant(). Other methods in

> Also what is the preferred method for MC way of setting out subsection > sizes after the fact? I am guessing I need to use an MCFixup? > How do I get an MCExpr to evaluate a method for the subsection size? > Is there an equivalent use in the places using MCFixup? > Do I need to add a new subclass to MCExpr for doing this? > > JimG, can you please comment on the MachO

Hi David, Thanks for your efforts here. I have a few comments on your patch, although I realise it's still a work in progress. +class ConstantPool { + MCSymbol *Label; + typedef std::vector<const MCExpr*> EntryVecTy; Use a SmallVector here? + MCSymbol *getLabel() {return Label;} + size_t getNumEntries() {return Entries.size();} + const MCExpr *getEntry(size_t Num) {return

On Thu, Oct 21, 2010 at 7:50 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Hmm, I wish we had this discussion way earlier.. >> >> How would I emit things in different subsections? I can do a high >> level switch to .ARM.attributes, and if I were emitting one blob from >> begin to end, using the higher level interface would be preferable,

> Hmm, I wish we had this discussion way earlier.. > > How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC

Hi Amara, Thanks for your suggestions. I have made the changes you suggested and added a new test to check that we print an error when parsing a non-ldr mnemonic with an operand containing `=`. The updated patch is attached. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Amara Emerson

Hi Jim, The diff below is not intended to be a patch, but a starting point. It is the shortest path (I hope) to getting LLVM to emit ARM mapping symbols to the ELF without changing any shared interfaces. Could you have a look at the FIXME comments and offer some pointers on how to get this code out of MCELFStreamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp

I have attached an initial patch that implements the ldr pseudo. It still needs some clean up and more tests, but I would like some feedback on the approach I used and if there are any objections to implementing it this way. Here is my approach: Add a finishParse() callback to the target asm parser This callback is invoked when the parse has finished successfully. It will be used to write out

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

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,

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Also what is the preferred method for MC way of setting out subsection >> sizes after the fact? I am guessing I need to use an MCFixup? >> How do I get an MCExpr to evaluate a method for the subsection size? >> Is there an equivalent use in the places using MCFixup? >>

Hello, I have some questions regarding folding operations with symbols during the instruction print stage with MC. At the moment I'm working with global symbols but i guess that other symbol types should be equivalent. My first question is how can i negate the address of a symbol? Consider this piece of code: char g_var[80]; char foo(int a) { return g_var[a]; } this gets compiles into

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

Daniel somehow replied to one of my previous commits on llvm-commits instead of this thread. On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi Michael, > > Two minor notes: > -- >> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp >> index 2cf65c1..02ac2be 100644 >> ---