similar to: [LLVMdev] Instruction Constraints Question

> 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

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

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

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 >

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

Yes, there is an easy way to fix this. MRMSrcMem 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

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding. Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination register should appear on the right and the mask should appear on the

I need to implement an instruction which has 2 read-write registers, so I added let Constraints = "$src1 = $dst, $mask = $mask_wb" in { ... def rm : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$mask_wb), (ins VR128:$src1, v128mem:$src2, VR128:$mask), ... } There is a problem since MRMSrcMem assumes the 2nd physical operand is a memory operand. See the section about

On Jul 9, 2012, at 4:15 PM, Manman Ren <mren at apple.com> wrote: > > I need to implement an instruction which has 2 read-write registers, so I added > let Constraints = "$src1 = $dst, $mask = $mask_wb" in { > ... > def rm : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$mask_wb), > (ins VR128:$src1, v128mem:$src2, VR128:$mask), > ... > }

On Tue, Feb 10, 2009 at 8:27 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Bill, > Sorry if I wasn't clear enough. I wasn't referring to multiclass's that > define other classes, but with using patterns inside of a multiclass to > reduce redundant code. > For example: > multiclass IntSubtract<SDNode node> > { > def _i8 : Pat<(sub

David Greene <dag at cray.com> writes: > In ToT, LowerVECTOR_SHUFFLE for x86 has this code: > > if (X86::isUNPCKLMask(SVOp)) > getTargetShuffleNode(getUNPCKLOpcode(VT) dl, VT, V1, V2, DAG); > > why would this not be: > > if (X86::isUNPCKLMask(SVOp)) > return SVOp; Ok, I discovered that Bruno did this in revisions 112934, 112942 and 113020 but the logs

FYI, The CRC64 intrinsics were renamed to CRC32 since there is no such thing. See below for details. Chad On May 26, 2011, at 4:13 PM, Chad Rosier wrote: > Author: mcrosier > Date: Thu May 26 18:13:19 2011 > New Revision: 132163 > > URL: http://llvm.org/viewvc/llvm-project?rev=132163&view=rev > Log: > Renamed llvm.x86.sse42.crc32 intrinsics; crc64 doesn't exist.

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

Here's the big RFC. A I've gone through and designed patterns for AVX, I quickly realized that the existing SSE pattern specification, while functional, is less than ideal in terms of maintenance. In particular, a number of nearly-identical patterns are specified all over for nearly-identical instructions. For example: let Constraints = "$src1 = $dst" in { multiclass

Bill, Sorry if I wasn't clear enough. I wasn't referring to multiclass's that define other classes, but with using patterns inside of a multiclass to reduce redundant code. For example: multiclass IntSubtract<SDNode node> { def _i8 : Pat<(sub GPRI8:$src0, GPRI8:$src1), (ADD_i8 GPRI8:$src0, (NEGATE_i8 GPRI8:$src1))>; def _i32 : Pat<(sub

Hi, I've come across a problem while working on an LLVM backend for a new target architecture. This architecture has two single-ported register files. Each instruction can only read one operand from each register file, but can write to either. I tried implementing it naïvely in TableGen with two definitions per instruction, so I had: def AllRegs : RegisterClass< ... (add interleave

Can someone explain the Constraints system in X86*.td? For example: let Constraints = "$src1 = $dst" This replaces isTwoAddress (according to svn logs), which I gather is how two-address instructions used to be marked for X86. Except isTwoAddress is still used in X86InstInfo.td. So what gives? What do these two properties actually do?

Also some missing _src()s and cosmetic changes. --- src/gallium/programs/galliumut/Makefile | 5 + .../programs/galliumut/gen_uureg_opcodes.sh | 29 +++ src/gallium/programs/galliumut/uureg.h | 196 ++++---------------- 3 files changed, 71 insertions(+), 159 deletions(-) create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh diff --git

It is inefficient and error-prone to recognize legal shuffles and then have isel repeat the process. For example, if the DAG combiner changes a shuffle in between legalization and isel, it may stop being legal and break isel. By legalizing to target-specific DAG nodes, we avoid that possibility and also make it much easier to match the shuffles during isel. On Feb 25, 2011, at 6:01 PM, David A.