search for: neverhassideeffects

All, TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. It's possible to override this behavior by setting neverHasSideEffects = 1. It was originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more convenient to use def : Pat<>, and sometimes custom instruction selection is required. As a result, many instructions are defined without a pattern, and we o...

...b/Target/Hexagon/HexagonInstrInfo.td >> +++ b/lib/Target/Hexagon/HexagonInstrInfo.td >> @@ -875,19 +875,19 @@ def LDrid_indexed : LDInst<(outs DoubleRegs:$dst), >> s11_3ImmPred:$offset)))]>; >> >> let mayLoad = 1, neverHasSideEffects = 1 in >> -def LDrid_GP : LDInst<(outs DoubleRegs:$dst), >> +def LDrid_GP : LDInst2<(outs DoubleRegs:$dst), >> (ins globaladdress:$global, u16Imm:$offset), >> "$dst=memd(#$global+$offset)", >> []>; >> &...

...lt;stoklund at 2pi.dk> wrote: > All, > > TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. > > It's possible to override this behavior by setting neverHasSideEffects = 1. > > It was originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more convenient to use def : Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without...

...lund at 2pi.dk>wrote: > All, > > TableGen likes to infer the MCID::UnmodeledSideEffects flag from an > instruction's pattern. When an instruction doesn't have a pattern, it is > assumed to have side effects. > > It's possible to override this behavior by setting neverHasSideEffects = 1. > > It was originally the intention that most instructions have patterns, but > that's not the way it worked out. It is often more convenient to use def : > Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined...

...you're saying. Are you proposing that all properties (may load, store, side effects) be explicitly added to all instructions, and the pattern only be used to produce warnings? Won't this hugely bloat the .td files? -Chris > > It's possible to override this behavior by setting neverHasSideEffects = 1. > > It was originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more convenient to use def : Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without...

On 08/21/12 16:49, Jim Grosbach wrote: > > I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. > > Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( This proposal would certainly make my life easier by having an easier to maintain insn table. For instance,...

On Aug 22, 2012, at 9:40 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: > On 08/21/12 16:49, Jim Grosbach wrote: >> >> I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. >> >> Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( > > This proposal would certainly make my life easier by having an easier to maintain insn tab...

...erence succeeds and a property is set to an inconsistent value, TableGen will issue an error. If inference succeeds and a property is set to a consistent value, TableGen will happily and silently go about its business. This will also handle migration for out-of-tree targets. They can replace 'neverHasSideEffects = 1' with 'hasSideEffects = 0', and any instructions without patterns will be pointed out for audit. /jakob

...uot;, [], IIC_DIV32>; // RDX:RAX/[mem64] = RAX,RDX let Defs = [RAX,RDX,EFLAGS], Uses = [RAX,RDX] in def DIV64m : RI<0xF7, MRM6m, (outs), (ins i64mem:$src), "div{q}\t$src", [], IIC_DIV64>; } It is a complete coincidence that these instructions happen to be missing neverHasSideEffects = 1 ;) Often, you can set the mayLoad flag as part of a multiclass when you define the *rm variant. X86 is the worst case because so many instructions can fold loads and stores. You can handle most of them by setting the mayLoad and mayStore flags in the big ArithBinOp multiclasses. You can see t...

...DX:RAX/[mem64] = RAX,RDX > let Defs = [RAX,RDX,EFLAGS], Uses = [RAX,RDX] in > def DIV64m : RI<0xF7, MRM6m, (outs), (ins i64mem:$src), > "div{q}\t$src", [], IIC_DIV64>; > } > > It is a complete coincidence that these instructions happen to be missing neverHasSideEffects = 1 ;) It's also a serious tblgen deficiency that we can't write patterns for these. Look at the terrible code in X86ISelDAGToDAG.cpp that is required to match these. > Often, you can set the mayLoad flag as part of a multiclass when you define the *rm variant. X86 is the worst case b...

...o use it. ... On multiply, the result implicit is placed in a 64 bit hi/lo register. // // Format: MFLO rx MIPS16e // Purpose: Move From LO Register // To copy the special purpose LO register to a GPR. // def Mflo16: FRR16_M_ins<0b10010, "mflo", IIAlu> { let Uses = [LO]; let neverHasSideEffects = 1; } // // Pseudo Instruction for mult // def MultRxRy16: FMULT16_ins<"mult", IIAlu> { let isCommutable = 1; let neverHasSideEffects = 1; let Defs = [HI, LO]; } def: Mips16Pattern<(mul CPU16Regs:$l, CPU16Regs:$r), [(MultRxRyRz16 CPU16Regs:$l, CPU16Regs:$...

Hi, I noticed, that execution domain is set to SSEPackedSingle for these instructions. Looks like a bug. let neverHasSideEffects = 1, ExeDomain = SSEPackedSingle in { def VEXTRACTF128rr : AVXAIi8<0x19, MRMDestReg, (outs VR128:$dst), - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use o...

Hi A bunch of instructions that I have defined in tablegen files get tagged with unmodeledSideEffect property. I have defined these instructions with no corresponding dag patterns. Is there a way i can avoid this property and say they do not have any side effects thanks shrey

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:

What have you tried? On Sun, Sep 16, 2012 at 3:34 PM, Kotler, Reed <rkotler at mips.com> wrote: > This Pattern class says it's possible but seems just to not work or maybe I'm using it incorrectly. > > Probably I will go and fix it when I'm done with mips16. > > > ________________________________________ > From: Hal Finkel [hfinkel at anl.gov] > Sent:

...RM2F128rr, X86::VPERM2F128rr, X86::VPERM2I128rr } On Wed, Jan 4, 2012 at 4:32 AM, Demikhovsky, Elena < elena.demikhovsky at intel.com> wrote: > Hi, > > I noticed, that execution domain is set to SSEPackedSingle for these > instructions. > Looks like a bug. > > let neverHasSideEffects = 1, ExeDomain = SSEPackedSingle in { > def VEXTRACTF128rr : AVXAIi8<0x19, MRMDestReg, (outs VR128:$dst), > > - Elena > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain...

This Pattern class says it's possible but seems just to not work or maybe I'm using it incorrectly. Probably I will go and fix it when I'm done with mips16. ________________________________________ From: Hal Finkel [hfinkel at anl.gov] Sent: Sunday, September 16, 2012 10:59 AM To: Anton Korobeynikov Cc: Kotler, Reed; LLVM-Dev ‎[llvmdev at cs.uiuc.edu]‎ Subject: Re: [LLVMdev] Pattern

...r, X86::VPERM2F128rr, X86::VPERM2I128rr } On Wed, Jan 4, 2012 at 4:32 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com<mailto:elena.demikhovsky at intel.com>> wrote: Hi, I noticed, that execution domain is set to SSEPackedSingle for these instructions. Looks like a bug. let neverHasSideEffects = 1, ExeDomain = SSEPackedSingle in { def VEXTRACTF128rr : AVXAIi8<0x19, MRMDestReg, (outs VR128:$dst), - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use o...

...tionPass::runOnFunction (this=0x448c770, F=...) at lib/CodeGen/MachineFunctionPass.cpp:33 For the purpose of this question, you can assume HexagonMachineScheduler.cpp == MachineScheduler.cpp and VLIWMachineScheduler == ScheduleDAGMI The instruction being moved is a simple call: let isCall = 1, neverHasSideEffects = 1, Defs = [D0, D1, D2, D3, D4, D5, D6, D7, R28, R31, P0, P1, P2, P3, LC0, LC1, SA0, SA1, USR] in { def CALLv3 : JInst<(outs), (ins calltarget:$dst), "call $dst", []>, Requires<[HasV3T]>; } CALLv3 <ga:@printf>, %D0<imp-def,dead>, %D1&lt...

...getting this error message from the tblgen: "In SU_routeInstr: Type inference contradiction found in node imm!" Here is my def Imm8Arg: Operand<i8> { let PrintMethod = "print Imm8Arg"; } // Intrinsic functions // int_stella_su_route let neverHasSideEffects = 1 in { def SU_routeInstr: MyInst<(outs),(ins Imm8Arg:$inport, Imm8Arg:$outline), "sel\t%o.ww.$outline=%i.ww.$inport", [(int_my_su_route imm:$inport, imm:$outline)]>; My intrinsic function is defined this way in the...