search for: iscodegenon

...2b 0xc9 0x8a 0xc8 0xdd 0x04 0x24 These are: subl %ecx, %ecx movb %al, %cl fldl (%esp) I've attached patches to bug#8873 which fix all these issues, but I'm not confident that I've fixed them the right way. The first two problems are caused by the instructions setting 'isCodeGenOnly = 1', which causes tblgen to miss them from the disassembler's tables. The code says: // The disassembler should know about this, but not the asmparser. let isCodeGenOnly = 1; However, that's not the effect which isCodeGenOnly has. Is the comment wrong, or is tblgen wrong? The p...

> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. This is exactly what I was missing. Thanks a ton! :) -- Sanjoy Das http://playingwithpointers.com

...instructions that need to trick all of codegen. Pseudos should be expanded as early as possible. Many of the instructions currently expanded in X86MCInstLower could be moved to the PostRA expansion pass. That would also allow them to be converted into pure isPseudo=1 instructions instead of just isCodeGenOnly=1. /jakob

Hello, I am trying to insert a .byte/.word in the beginning of a specific LLVM IR instruction when it prints out in assembly (the inserted ‘instruction' only appears in assembly, not in LLVM IR), and I am guessing the best way to do that is to insert it in SelectionDAG as it strips down some LLVM IR instructions when it’s lowered. Can I get some guidance on what function I should use to insert

...perand I want thanks to the fact that the AsmPrinter is constructed with a TargetMachine. That said perhaps there are extra constraints that require doing the lowering in MCCodeEmitter, unfortunately I can't tell exactly what is the advantage of lowering that late. These pseudos are marked as isCodegenOnly = 0 so if I lower them in AsmPrinter my understanding is that now I have to change them to isCodegenOnly = 1 and then teach AsmParser to recognize them (I would need to use the reloc model there too). Does this make sense? Alternatively I was considering adding two new pseudos like RISCV::CALL_P...

...er. It looks like the "ADD32rr_alt" instruction should have GR32 operands, not GR16. Attached you can find a patch, which should fix the problem. But even with the change I can not decode e.g. "0x03 0xC1" (should be "addl %ecx, %eax") only if I remove the "isCodeGenOnly = 1" line it works. Looking for help. -- Marius Wachtler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100405/2c731c58/attachment.html> -------------- next part -------------- A non-text attachme...

...ns that need to trick all of codegen. > > Pseudos should be expanded as early as possible. Many of the instructions currently expanded in X86MCInstLower could be moved to the PostRA expansion pass. That would also allow them to be converted into pure isPseudo=1 instructions instead of just isCodeGenOnly=1. FWIW, even those expanded at MCLowering time can be pure pseudos. There is no need to use isCodeGenOnly definitions for any new code. Those that exist are pure legacy. -Jim

0x0f 0x6f 0xc8 And 0x0f 0x7f 0xc1 Should both be movq % mm0, % mm1. (AT&T) However, llvm 3.4 at least does not recognise the second variant as being a valid instruction. We are currently compiling up latest src incase it has been fixed. If not, could someone take a look or recommend how to fix? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL:

> 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

Hi, I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing). I'm basing the code on the PowerPC version, which itself is based on the X86 version. This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that below), so I know it's close. However, the PowerPC

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint

...Ty<0>]>, [SDNPHasChain, SDNPOptInGlue, SDNPOutGlue, SDNPVariadic]>; def my_ret : SDNode<"MyISD::RET_FLAG", SDTNone, [SDNPHasChain, SDNPOptInGlue, SDNPVariadic]>; let hasCtrlDep = 1, hasSideEffects = 1, isCodeGenOnly = 1, Defs = [SP], Uses = [SP] in { def ADJCALLSTACKDOWN : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2), [(MyCallseqStart timm:$amt1, timm:$amt2)]>; def ADJCALLSTACKUP : Pseudo<(outs),...

...gt; If there are no objections, I'd like to start working on this soon... > > For the AMDGPU target this implies that RC->getSize will no longer be > available in the MC layer. Another advantage of this work that hasn't been mentioned yet is it will reduce the number of uses of isCodeGenOnly. The comment in Target.td indicates the long-term plan is to remove the distinction between isPseudo and isCodeGenOnly. A closely related to variable-sized register classes is the case where you have multiple registers with the same AsmName. This crops up in the same kind of cases where you have...

...Intrinsic::connex_repeat_x_times); > > // See http://llvm.org/docs/doxygen/html/classllvm_1_1IRBuilder.html > aB.CreateCall(repeatFunc); //, ECValue); > > > Then, in the back end, in InstrInfo.td I write: > let hasSideEffects = 1, isCodeGenOnly = 1 in { > //let Pattern = [(int_connex_repeat_x_times)] in > def REPEAT_X_TIMES : ImmediateInstruction< 0b111111, > (outs), > (ins), >...

...asm-parser > only alias) cannot be detected automatically. To avoid a build break, the > patch demotes the FatalError to a simple Warning, which will now show up on > those handfull of ARM instruction patterns. To remove those warnings, we > could either mark the instructions as "isCodeGenOnly" or implement proper > custom matchers. I'd prefer to leave this up to the ARM back-end > maintainers, though … The instructions that have an AsmParser alias should definitely be marked isCodeGenOnly. It’s a (probably harmless at the moment) bug if they’re not. Please go ahead an...

...ere looks reasonable, and may be simplify parsing/matching complex operands. This does look like a somewhat independent problem, however, and I'd prefer to possibly addressing it as a second step later on ... > The instructions that have an AsmParser alias should definitely be > marked isCodeGenOnly. It’s a (probably harmless at the moment) bug > if they’re not. Please go ahead and update them. That way the build > will stay warning-clean after this goes in. I suggest doing that > separately as an incremental patch before landing this one since > it’s preparatory work, rather tha...

Does anybody know is there is a way to print all the property values for a given def? For example I have a following instruction definition in the .td file let isReturn = 1, isTerminator = 1, hasDelaySlot=1, isBarrier = 1, isCodeGenOnly = 1, Inst = 0x44004800 in { def RET : InstBR<0x1, (outs), (ins), "l.jr\tr9", [(retflag)]>; } Ultimately when I track it down the def tracks down to class Instruction in include/llvm/Target/Target.td, ie. class Instruction { string Namesp...

Hi Alex, You might find it useful to look at how lib/Target/PowerPC/PPCCTRLoops.cpp works. -Hal ----- Original Message ----- > From: "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, May 30, 2016 5:09:37 PM > Subject: [llvm-dev] Back end with special loop instructions > > Hello.

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

Hello. I'm writing a back end for my research SIMD processor that has an assembly language that is blocked structured, with one-level loops. An example program with my assembly language: REPEAT_X_TIMES(Param2) R0 = LS[offset_A]; END_REPEAT; The LLVM code somewhat equivalent to the above ASM program is: vector.body: %index = phi i64 [