similar to: [LLVMdev] [TableGen][AsmParser][MC] isAsmParserOnly flag in class Instruction

Hi Vladimir, ARM does similar things for complex assembly pseudos. Have a look at the definition and use of AsmPseudoInst in the ARM backend. They’re not typically expanding to multiple “real” instructions, but that’s an implementation detail, not a constraint. -Jim On Oct 1, 2013, at 5:36 AM, Vladimir Medic <Vladimir.Medic at imgtec.com> wrote: > Hi all, > I'm working on llvm

Hi Jim, I did look at the ARMAsmParser and it seems to me that it is using a switch/case construct to change the opcode and the operands, but this construct may become too large eventually. I was wondering if it is possible to use isAsmParser only flag to call dedicated methods, like dedicated parsers for AsmOperands. Regards Vladimir ________________________________ From: Jim Grosbach [grosbach

I'm trying to build a standalone assembler for Mips using AsmParser. Following the lead of X86, ARM and MBlaze I have run tblgen -gen-asm-matcher on Mips.td to produce tables and methods to aid the parser (MipsAsmParser.cpp) which is a stripped down ARM implementation. I am getting an assertion for what I believe are multiple register definitions with the same name. llvm-tblgen:

Hi Jack, You're running into a fundamental problem with the current table generated asmmatcher. Specifically, wants to believe that assembly parsing is context insensitive, or at least close enough that operands can be parsed w/o knowing the context of the instruction. Its idea is to use the operand types to disambiguate which instruction should be selected. It sounds like MIPS 64vs.32 does

Hi Daniel, I defined checkEarlyTargetMatchPredicate() to explicitly check for the tied operands, and it worked. I could define an alias like: InstAlias<"oldOP $rd, $rd, $rs1", (NEWOP $rd, $rs1)> However, I had to additionally change AsmMatcherEmitter 'Hack' variable setting to allow the repeated operand $rd in the AsmString. Do you or anyone else know the history

I'm trying to build a standalone assembler for Mips using AsmParser and I'm facing a problem with assembly directives. Mips assembler has following syntax for .set directive .set reorder or .set noreorder which allow/disallow assembler to change the order of instructions in the block that follows. As the implemented AsmParser requires .set directive to have the following syntax:

Hello, InstAlias does not allow tied operands (repeated operands) in the asm string to be matched. It seems this situation is explicitly prevented in AsmMatcherEmitter.cpp: if (!Hack) PrintFatalError(TheDef->getLoc(), "ERROR: matchable with tied operand '" + Tok + "' can never be matched!");

On Jan 31, 2012, at 1:26 PM, Carter, Jack wrote: > I'm trying to build a standalone assembler for Mips using AsmParser. > > Following the lead of X86, ARM and MBlaze I have run tblgen -gen-asm-matcher on Mips.td to produce tables and methods to aid the parser (MipsAsmParser.cpp) which is a stripped down ARM implementation. > > I am getting an assertion for what I believe are

Hi, On Instructions you can use checkEarlyTargetMatchPredicate() to check that the operands are the same. There's an example of that in MipsAsmParser.cpp for DATI and DAHI. I can't think of a reason TableGen couldn't be made to allow this for InstAlias too. > On 15 Dec 2017, at 02:12, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > InstAlias

Hi Jim, thank you for the quick response. I have used InstAlias in some cases, but these are really simple pseudo instructions where the pseudo instruction is more like a special case of existing one, like using fixed operand or simply a more human understandable way of presenting an operation. I know that there are predicates available to improve matching, but can InstAlias use conditions to

Hi all, I'm trying to solve a problem that we have in implementation of the assembler for Mips platform in llvm. Mips has some pseudo instructions that, depending on the arguments can be emitted as one or more real instructions by the assembler. For example load immediate instruction can have multiple expansions depending on a size of immediate operand: This expansion is for 0 ≤ j ≤ 65535. li

Hi Vladimir, The pass you refer to isn't used by the assembler at all. That's strictly a compiler codegen thing. The assembler equivalents are expressed via InstAlias constructions. Again, though, those are for a single output instruction, so you need something more. Sprecifically, you can handle assembly pseudo-instructions in C++ code. Something like the ARM assembler's

Hi ES, From what I understand instruction parsing is divided into two parts: - Parsing an operand list (XXXAsmParser::ParseInstruction) - Turning the operand list into an actual instruction (XXXAsmParser::MatchAndEmitInstruction) The second part does the validation (e.g. how many operands, what kind, etc) while the first part only does the parsing. That's why I think in the first part

On Wed, 11 Jan 2006, Vladimir A. Merzliakov wrote: > I can't build LLVM CFE after this patchs > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030639.html > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030654.html This is most likely because you have conflict markers in the generated files in the lib/AsmParser directory. Try removing

Hello With the latest LLVM from Subversion (rev48737 from http://llvm.org/svn/llvm-project/llvm/trunk) I'm getting make[2]: Entering directory `/usr/src/Lang/llvm/_Obj/lib/AsmParser' llvm[2]: Flexing Lexer.l llvm[2]: Compiling Lexer.cpp for Debug build /usr/src/Lang/llvm/lib/AsmParser/Lexer.l: In function 'int llvmAsmlex()': /usr/src/Lang/llvm/lib/AsmParser/Lexer.l:278: error:

Hello, The recent renamings moved some IR-related files and directories to more logical places. Is there a plan to rename lib/AsmParser as well? This directory name is somewhat misleading, because the code in it parses IR. In fact, nothing mentions AsmParser in the code inside that dir, except the build files. The name creates a confusion with other AsmParser citizens of LLVM like

Hello all, My partner was just debugging a project that had tried to call a function without arguments in the code but the declaration wasn't declared with a void parameter list. It failed with an assertion that something was trying to ++ past the end of an ilist. I seem to remember Chris Lattner saying when he made the hand written AsmParser that it wasn't intended to be very robust

For VC++, I solved this by having bison/flex put the files into the obj directories. I also have it unconditionally regenerate the files if bison/flex is available, and copy them from src if they are not. Chris Lattner wrote: > On Wed, 11 Jan 2006, Vladimir A. Merzliakov wrote: > >> I can't build LLVM CFE after this patchs >>

No solutions come to mind. Conflicts are conflicts and must be resolved manually. This situation should only occur if you change the .l/.y file and then update the .h/.cpp files after someone else has changed the .l/.y file and regenerated the .h and .cpp. That doesn't seem like a high frequency scenario that we need to worry about. Not sure there's much we could do even if it was. Reid.

I can't build LLVM CFE after this patchs http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030639.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030654.html Build terminated with messages: --8X---------------------------------------------- llvm[2]: Compiling Lexer.cpp for Debug build In file included from