similar to: [LLVMdev] [RFC] MS-style inline assembly

> > 1. How is clang going to discover the input operands, output operands, > constraints, and clobbered registers? > The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach. > In the above example, the two asm statments are not valid assembly. > Thus, the AsmParser cannot parse these statements without some >

On Aug 6, 2012, at 1:03 PM, João Matos wrote: > 1. How is clang going to discover the input operands, output operands, > constraints, and clobbered registers? > > The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach. Glad you agree. We really shouldn't be replicating information in the frontend; this very error

Hi, I try to create a backend to support AsmParser, but it hasn't the red part as below. I find the Mips has this. Do you know how to make it appear? Jonathan #ifdef GET_ASSEMBLER_HEADER #undef GET_ASSEMBLER_HEADER // This should be included into the middle of the declaration of // your subclasses implementation of MCTargetAsmParser. unsigned ComputeAvailableFeatures(uint64_t

Dear All, I am following a flow to generate object files(.o) from input (.s assembly) files. The input .s is given to AsmParser, which creates MCInst after matching instruction opcode. These MCInst are converted to MCStream and then finally emitting to an object file using Target Code Emitter. I am considering whether hazard recognition can be done on the list of MCInst, which I get after

Hi, Imagine that your backend has valid asm instruction written like this: "%x mnem %y, %z" And user puts it as inline assembler: __asm__ ("%x mnem %y, %z"); It can not be parsed with current llvm asm parser, because it starts with % (moreover it has mnemonic in second place) Say you written pass, that makes it "mnem %x, %y, %z". Now this guy can be parsed, but

Hi, This is really basic block level pass. It is no difference what is level, problem is the same. After fixing for asm parser, assembler syntax is no more valid for backend, without processing with asm parser. May be it will be solution to process inline asm on insn printer level to remove syntax fixes. But just switch it off without lto will make compiler do less job P.S. sorry for dup,

Hello, I am working on backend development and would like to utilize my target's MCAsmParser inside of an MCInst-level class implementation. I noticed that the AsmParser is registered with the target registry however I am having no luck grepping for a "template" of how to instantiate it and have yet to find specific documentation on how it is done. Any ideas or help is greatly

Jonathan <gamma_chen at yahoo.com.tw> wrote: > I try to create a backend to support AsmParser, but it hasn't the red part > as below. I find the Mips has this. Do you know how to make it appear? > > Jonathan > > #ifdef GET_ASSEMBLER_HEADER > #undef GET_ASSEMBLER_HEADER > // This should be included into the middle of the declaration of > // your subclasses

Hi, In LTO we have AsmParser that process inline assembler instructions to MCInst and I want to fix some inline assembler in order to conform its rules (do not start with non-identifier and so on) because asm syntax of our backend allows some incompatible patterns. In order to do this I am adding IR-level target-specific pass. But those fixes shall not be applied when there is no AsmParser later

GCC-style inline assembly is notoriously hard to write correctly, because it is the user's responsibility to tell the compiler about the requirements of the assembly (inputs, output, modified registers, memory access), and getting this wrong results in silently generating incorrect code. This is also dependent on register allocation and scheduling decisions made by the compiler, so an inline

> > I'm not sure we would want to store the MCInst(s) in the AST. After we're > done with semantic checking and we've created the IR representation (with > inputs, outputs, clobbers, constraints, etc.), I don't think there's a > reason for the MCInst(s) to persist. > I was assuming that MCInst would already provide a lot of the needed information, like

Hello. Sometimes the constraints imposed on an instruction's encoding are too complex to be described in tablegen alone. In such cases a custom decoder method is implemented. This makes sense when the decoding itself is very complex, but it is wasteful to do it only when checking additional constraints. This is because: 1. a custom decoder method has to decode operands, set opcodes, etc. -

Hi Mihail, > static DecodeStatus CheckNEONConstraint(const MCInst &Inst, unsigned Insn) [...] > ConstraintCheckMethod = "CheckNEONConstraint" In general I like the idea of an instruction-validation method. I think it could also potentially solve the SoftFail/UNPREDICTABLE issues that are looming (and partially resolved for decoding at present). However, I think that to cope

Hi, I want to enable some target-specific functionality only if current build is 2nd LTO stage (i.e. optimizer called from plugin). What is best and recommended way to do it? --- With best regards, Konstantin

Hi Ulrich, Thank you for looking at this. Apologies again for taking unjustifiably long to get back to you. This is really good stuff and I very much want to see this go in. I like it enough I’m going to try to talk you into doing even more work on improving this code. ;) Fair warning up front: You’re digging into some pretty fundamental problems in how the assemblers and code generators like to

On Feb 15, 2010, at 12:53 PM, Chris Lattner wrote: > > On Feb 15, 2010, at 10:00 AM, David Greene wrote: > >> On Monday 15 February 2010 11:54:25 Óscar Fuentes wrote: >>> David Greene <dag at cray.com> writes: >>>> Sorry, I botched a commit and broke the build. I've just committed a >>>> fix. >>>> >>>> So expect

Hi Jim, > Thank you for looking at this. Apologies again for taking > unjustifiably long to get back to you. This is really good stuff and > I very much want to see this go in. I like it enough I’m going to > try to talk you into doing even more work on improving this code. ;) > > Fair warning up front: You’re digging into some pretty fundamental > problems in how the

> But where is the flat set? Maybe I can debug and check what is going on. The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc of your build directory. > Some additional information: > > MCInst opcode: 0x7cb > Decode Index: 0x1e I had assumed this would have dissembled to '// Inst #234 = BC' which does have the branch flag set, but I think that

We have DELL servers with CENTOS 3 and 4 installed. Application is client/server type. Does there has way monitor invidual client (PC) network traffic to server? Thanks. ______________________________________________________________________________________________________ ?????????Yahoo!??????2.0????????????? http://tw.mg0.mail.yahoo.com/dc/landing

Bill, thanks for your comments. I'll respond to them individually. I've attached a new revision of the patch that addresses them. Patch built and tested against SVN 79487, with the additional attached fix that fixes an Intel table bug. Sean On 2009/08/18, at 0:57, Bill Wendling wrote: > 0. Watch out for tabs! Fixed. Thanks. > 1. Includes like this "#include