search for: tiedto

...4. >> I haven't settled on a final version of the operand flags (for registers) >> syntax, but at the moment I'm thinking of something like this: >> - The IsDef flag is implied by the use of the register before the '=', >> unless it's implicit. >> - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by >> the instruction description. (I believe that's true in all cases, but I'm >> not 100% sure). >> - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like >> 'implicit', ...

...MachineBasicBlock::dump() as close as possible to the format you use > for serializing. > [...] > > Ideally the new syntax would replace the existing print/dump syntax. The > new syntax will lead to certain missing information when > this information can be inferred (e.g. the TiedTo and IsEarlyClobber > attributes for register operands that I mentioned earlier in this thread), > so maybe we could have some sort of verbose dumping option where > absolutely everything is dumped. I think that the new syntax is less readable than the current format of the "dump&qu...

...basically compute the address RSP + 1 * 0 + 4. I haven't settled on a final version of the operand flags (for registers) syntax, but at the moment I'm thinking of something like this: - The IsDef flag is implied by the use of the register before the '=', unless it's implicit. - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by the instruction description. (I believe that's true in all cases, but I'm not 100% sure). - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like 'implicit', 'undef', 'kill', '...

...e format you use > >> for serializing. > >> [...] > >> > >> Ideally the new syntax would replace the existing print/dump syntax. The > >> new syntax will lead to certain missing information when > >> this information can be inferred (e.g. the TiedTo and IsEarlyClobber > >> attributes for register operands that I mentioned earlier in this > thread), > >> so maybe we could have some sort of verbose dumping option where > >> absolutely everything is dumped. > > > > > > I think that the new syntax is...

...t;>>> [...] >>>>> >>>>> Ideally the new syntax would replace the existing print/dump syntax. >>>>> The >>>>> new syntax will lead to certain missing information when >>>>> this information can be inferred (e.g. the TiedTo and IsEarlyClobber >>>>> attributes for register operands that I mentioned earlier in this >>>>> thread), >>>>> so maybe we could have some sort of verbose dumping option where >>>>> absolutely everything is dumped. >>>> >&...

...> = COPY %vreg9; GR64:%vreg9 %RDX<def> = COPY %vreg10; GR64:%vreg10 %R10<def> = COPY %vreg11; GR64:%vreg11 %R8<def> = COPY %vreg12; GR64:%vreg12 INLINEASM <es:syscall > [sideeffect] [attdialect], $0:[regdef], %RAX<imp-def,tied5>, $1:[reguse tiedto:$0], %vreg2<tied3>, $2:[reguse], %RDI, $3:[reguse], %RSI, $4:[reguse], %RDX, $5:[reguse], %R10, $6:[reguse], %R8, $7:[clobber], %EFLAGS<earlyclobber,imp-def>, $8:[clobber], %CX<earlyclobber,imp-def>, $9:[clobber], %R11<earlyclobber,imp-def>, <<badref>>; GR64:...

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

Hi all, I would like to propose a text-based, human readable format that will be used to serialize the machine level IR. The major goal of this format is to allow LLVM to save the machine level IR after any code generation pass and then to load it again and continue running passes on the machine level IR. The primary use case of this format is to enable easier testing process for the code