search for: asmmatcher

...l, this flag is not available to the AsmParser nor it can be accessed via MCInstrDesc class that we import as externally defined. In fact, the only thing it is used for is to avoid generating codeGen info for these instructions in tableGen. So, I was wandering if there is a plan to use this flag in asmMatcher or at least make it available in AsmParser? Kind regards Vladimir Medic -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131001/f719e941/attachment.html>

...l, this flag is not available to the AsmParser nor it can be accessed via MCInstrDesc class that we import as externally defined. In fact, the only thing it is used for is to avoid generating codeGen info for these instructions in tableGen. So, I was wandering if there is a plan to use this flag in asmMatcher or at least make it available in AsmParser? > > Kind regards > > Vladimir Medic > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev --...

...l, this flag is not available to the AsmParser nor it can be accessed via MCInstrDesc class that we import as externally defined. In fact, the only thing it is used for is to avoid generating codeGen info for these instructions in tableGen. So, I was wandering if there is a plan to use this flag in asmMatcher or at least make it available in AsmParser? Kind regards Vladimir Medic _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/> http://lists.cs.uiuc.edu...

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...

...en register (in Mips $28 and $gp are the same) it would be quite useful for the llvm-mc assembler which has to handle cases where there are multiple names for the same register. A quick recursive grep shows that no target is currently using this. It is also not use when generating <target>GenAsmMatcher.inc. If this is the case, I will try and incorporate AltNames so the strings get correctly matched in the AsmMatcher. Cheers, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120211/0b223af9/attachment...

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 with this 'Hack' flag? Thanks, Ana. diff --git a/utils/TableGen/AsmMatcherEmitter.cpp b/utils/TableGen/AsmMatcherEmitter.cpp index 1a820a5..252fd51 100644 -...

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: