search for: tied_to

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 does not appear anywhere in source/lib/Target/X86/* yet TIED_TO occurs in 162 of the OperandInfo's in buil...

...l operand is a memory operand. See the section about MRMSrcMem in RecognizableInstr::emitInstructionSpecifier. And the above gives us $dst, $mask_wb, $src1, $mem, $mask, and $mask_wb is the second physical operand. I thought about using "$mask_wb = $mask", but it breaks the assumption of TIED_TO LhsIdx > RhsIdx. Is adding another addressing mode a good idea? Any pointer is appreciated. Thanks, Manman

...em assumes register, memory, vvvv register if VEX_4VOp3 is true and assumes register, vvvv register, memory if VEX_4V is true. I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) I will fix those to handle this instruction. Thanks, Manman On Jul 9, 2012, at 10:07 PM, Evan Cheng wrote: > > > On Jul 9, 2012, at 4:15 PM, Manman Ren <mren at apple.com> wrote: > >> >> I need to implement an instruction which has 2...

...tion about MRMSrcMem in RecognizableInstr::emitInstructionSpecifier. Can this be fixed? Evan > And the above gives us $dst, $mask_wb, $src1, $mem, $mask, and $mask_wb is the second physical operand. > > I thought about using "$mask_wb = $mask", but it breaks the assumption of TIED_TO LhsIdx > RhsIdx. > Is adding another addressing mode a good idea? > > Any pointer is appreciated. > Thanks, > Manman > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://list...

...ory, vvvv register if VEX_4VOp3 is true and > assumes register, vvvv register, memory if VEX_4V is true. > > I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few > places where we assume only the 2nd operand can be tied-to: > Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) > I will fix those to handle this instruction. > > Thanks, > Manman > > On Jul 9, 2012, at 10:07 PM, Evan Cheng wrote: > > > > > > > On Jul 9, 2012, at 4:15 PM, Manman Ren <mren at apple.com> wrote: > > > >> &gt...

...manual, no two of the destination register, vector index register and mask register can be the same. The patterns in X86InstrSSE.td are missing this constraint and it's possible to generate an illegal instruction. It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER and TIED_TO. We would need to add a constraint such as "$dst != $src1, $dst != $mask, $src1 != $mask" to the current patterns to enforce the rules. Is there another mechanism to suport a constraint like this or is hacking TableGen the best way to do it? If the latter, does anyone have a sense of h...

> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER > and TIED_TO. We would need to add a constraint such as "$dst != $src1, > $dst != $mask, $src1 != $mask" to the current patterns to enforce the > rules. You can emulate such constraints via early clobbing. Just mark dst as early clobbing. > Is there another mechanism to suport a constraint...

>> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER >> and TIED_TO. We would need to add a constraint such as "$dst != $src1, >> $dst != $mask, $src1 != $mask" to the current patterns to enforce the >> rules. > You can emulate such constraints via early clobbing. Just mark dst as > early clobbing. How would that (or any early clobberi...

On Wed, Jan 23, 2013 at 4:40 PM, Tim Northover <t.p.northover at gmail.com>wrote: > >> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER > >> and TIED_TO. We would need to add a constraint such as "$dst != $src1, > >> $dst != $mask, $src1 != $mask" to the current patterns to enforce the > >> rules. > > You can emulate such constraints via early clobbing. Just mark dst as > > early clobbing. > > How woul...

Anton Korobeynikov <anton at korobeynikov.info> writes: >> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER >> and TIED_TO. We would need to add a constraint such as "$dst != $src1, >> $dst != $mask, $src1 != $mask" to the current patterns to enforce the >> rules. > You can emulate such constraints via early clobbing. Just mark dst as > early clobbing. Actually, I've always wondered w...

On 1/23/2013 3:33 PM, Anton Korobeynikov wrote: >> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER >> and TIED_TO. We would need to add a constraint such as "$dst != $src1, >> $dst != $mask, $src1 != $mask" to the current patterns to enforce the >> rules. > You can emulate such constraints via early clobbing. Just mark dst as > early clobbing. How would you emulate src1 != mask vi...

On Jan 23, 2013, at 2:38 PM, dag at cray.com wrote: > Anton Korobeynikov <anton at korobeynikov.info> writes: > >>> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER >>> and TIED_TO. We would need to add a constraint such as "$dst != $src1, >>> $dst != $mask, $src1 != $mask" to the current patterns to enforce the >>> rules. > >> You can emulate such constraints via early clobbing. Just mark dst as >> early clobbing. > > Actua...

...FormMask) == X86II::Pseudo) > - return 0; > - if (Desc.TSFlags & X86II::REX_W) > - REX |= 1 << 3; > - > - unsigned NumOps = Desc.getNumOperands(); > - if (NumOps) { > - bool isTwoAddr = NumOps > 1 && > - Desc.getOperandConstraint(1, TOI::TIED_TO) != -1; > - > - // If it accesses SPL, BPL, SIL, or DIL, then it requires a > 0x40 REX prefix. > - unsigned i = isTwoAddr ? 1 : 0; > - for (unsigned e = NumOps; i != e; ++i) { > - const MachineOperand& MO = MI.getOperand(i); > - if (MO.isRegister()) { &...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And