similar to: [LLVMdev] [PATCH v2] MC: handle .cfi_startproc simple

Really sorry I missed this. Just found it looking for something else in my inbox. I think we should support this but * We should still err on other identifiers ".cfi_startport bar" is invalid. * If I read the gas documentation correctly, the effect of "simple" is to skip the initial cfi instructions. We should test if that is the case and implement it too. Accepting and

Hi Craig and Rail, At Movidius, we have had to make a few changes to ‘MCAsmStreamer’ to support our assembler which is not ‘gas’ compliant. Earlier versions of LLVM (3.1 and 3.2) did have a separate header for ‘MCAsmStreamer’, and we had previously sub-classed this. The following are modifications that we have had to make because although ‘MCAsmStreamer’ does most of what we need,

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

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 all, I'm working on a new target, a 16 bit microcontroller, in the process of learning the LLVM backend things. It's going well so far, but I have a question: I'd like to use a pure MCAsmStreamer and not have another layer of glue. Right now, I have the following to make it compile: --- using namespace llvm; namespace { class HCS12AsmPrinter : public AsmPrinter { public:

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

Hi all, I think that I came somewhat closer to a solution for splitting a MachineBasicBlock for a PSEUDO_CALL_R instruction and having a label to the new MBB: For following piece of code: --- typedef int callme_t(int a, int b); callme_t* c01; int foo(int a, int b) { return c01(a,b); // MachineBasicBlock will be split at call instruction } --- I have initially following correspondence: BB1

Hi, According to the GNU as documentation [1], .cfi_startproc simple is a valid directive. Unfortunately, LLVM complains with: error: invalid instruction mnemonic 'simple' I happened to notice it while attempting to compile linux.git with clang: see arch/x86/ia32/ia32entry.S:75. [1]: http://sourceware.org/binutils/docs-2.22/as/Pseudo-Ops.html#Pseudo-Ops Thanks.

Hello, There is an issue in the latest Sparc code: while we can encode POPC, decode results in crash in llvm-mc $ echo "popc %g1, %g2" | ./Release+Asserts/bin/llvm-mc -assemble -triple=sparcv9 -show-encoding .text popc %g1, %g2 ! encoding: [0x85,0x70,0x00,0x01] $ echo "0x85,0x70,0x00,0x01"|./Release+Asserts/bin/llvm-mc -disassemble -triple=sparcv9

Any ideas on this bug? Thanks. On Wed, Jul 29, 2015 at 12:17 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > Hello, > > There is an issue in the latest Sparc code: while we can encode POPC, > decode results in crash in llvm-mc > > $ echo "popc %g1, %g2" | ./Release+Asserts/bin/llvm-mc -assemble > -triple=sparcv9 -show-encoding > .text > popc

On Sep 29, 2010, at 4:27 PM, Jason Kim wrote: >> Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an equivalent function to do what needs done for object files. Perhaps there isn't one (yet) and that's what's leading to the confusion? > > LOL :-) Yes, maybe that's it. Included is a patch w comments that >

It is common for targets to have specific assembly directives they need to support. For example, ppc has ".tc" and ARM has its own set of directives for describing EH tables. On the parser side we already had a target parser interface, but on the streamer side they all had to go into the basic MCStreamer. We also had just one MCAsmStreamer which had to implement them all. In r192181 I

Hi David, The way I imagined that we might want to extend the MCStreamer API (this was motivated by DIEData) is by allowing clients to move bytes and fixups into the MC layer. This is the sort of API that I was imagining: void MoveAndEmitFragment(SmallVectorImpl<char> &&Data, SmallVectorImpl<MCFixup> &&Fixups); Note that this mirrors the

> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Just in case it interests anyone else, I'm playing around with trying to broaden the MCStreamer API to allow for emission of bytes without copying the contents into a local buffer first (either because you already have a buffer, or the bytes are already present in another file, etc) in

> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Just in case it

I'll look into it, thanks for the report. On Thu, Jul 30, 2015 at 11:01 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Any ideas on this bug? > > Thanks. > > > On Wed, Jul 29, 2015 at 12:17 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hello, >> >> There is an issue in the latest Sparc code: while we can encode POPC, >> decode

Hi All, Bruno asked me to write up a short email about the direction we're going with llvm-mc and how it interacts with the object writer stuff. My hope was that .o writing could be basically done without worrying about llvm-mc, but I think we've reached the point where it is useful to talk about how the two will interact in the future. It turns out that I also failed in the

Hi James, Not sure if you've already found the problem but I've been looking at this issue a bit as a way to learn. What I've seen is that the wrong operand names are used for the instruction which causes the decoder emitter to fail to recognize the operands. The attached patch changes the names of the operands and adds a test for the disassembly of the instruction. I haven't

> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Just in case it

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h