search for: hasctrldep

...with other "simple" loads in the PowerPC backend, > > canFoldAsLoad is set but mayLoad is not (is this wrong)? > > Hmm. So far we've got: mayLoad, mayStore, canFoldAsLoad and > hasUnmodeledSideEffects as candidates. > > Looking at Target.td, I see that I missed hasCtrlDep which seems to be > exactly what we're looking for, though it doesn't appear to actually > be used for *anything* at the moment. I'm not sure how I missed it > before. > > Unless anyone comes up with a better idea (or just a reason why this > idea is bad) I think I...

...rk for me. As is > the case with other "simple" loads in the PowerPC backend, > canFoldAsLoad is set but mayLoad is not (is this wrong)? Hmm. So far we've got: mayLoad, mayStore, canFoldAsLoad and hasUnmodeledSideEffects as candidates. Looking at Target.td, I see that I missed hasCtrlDep which seems to be exactly what we're looking for, though it doesn't appear to actually be used for *anything* at the moment. I'm not sure how I missed it before. Unless anyone comes up with a better idea (or just a reason why this idea is bad) I think I'll send a patch making the p...

> If it is not being used, maybe we should change it to be > doesNotNeedChain? That sounded like a really good idea until I started to actually go through removing all traces of hasCtrlDep from other Targets. I felt really bad about wiping those flags people had carefully put on their instructions, even if useless. > I am not sure what kind of load does not need to be chained (prefetch?), but I'd prefer to keep the system friendly if at > all possible. They'll be fewer...

On Sat, 23 Jun 2012 21:25:48 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > On Sat, 23 Jun 2012 21:18:37 -0500 > Hal Finkel <hfinkel at anl.gov> wrote: > > > On Sat, 23 Jun 2012 22:28:55 +0100 > > Tim Northover <t.p.northover at gmail.com> wrote: > > > > > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > > > >

...tting hasSideEffects = 1 on the RD Instruction seemed like a logical idea, but only resulting in tblgen telling me he already inferred that. After some discussion, it seems that the problem here is that the RD nodes don't get a chain input and output in the selected DAG. As a second try, I set hasCtrlDep = 1 on the RD instruction, assuming it would ensure that RD would always use chain operands (the comment on hasCtrlDep says "Does this instruction r/w ctrl-flow chains?"). However, this didn't help at all. In fact, it seems that the value of hasCtrlDep is totally ignored by tblgen. It...

...-def LDd_GP : LDInst<(outs DoubleRegs:$dst), >> +def LDd_GP : LDInst2<(outs DoubleRegs:$dst), >> (ins globaladdress:$global), >> "$dst=memd(#$global)", >> []>; >> >> let isPredicable = 1, mayLoad = 1, hasCtrlDep = 1, neverHasSideEffects = 1 in >> -def POST_LDrid : LDInstPI<(outs DoubleRegs:$dst, IntRegs:$dst2), >> +def POST_LDrid : LDInst2PI<(outs DoubleRegs:$dst, IntRegs:$dst2), >> (ins IntRegs:$src1, s4Imm:$offset), >> "$dst = memd($src1++#$o...

...uot;MYISD::CALL", SDT_MYCall, [SDNPHasChain, SDNPOptInGlue, SDNPOutGlue, SDNPVariadic]>; def MYret : SDNode<"MYISD::RET_FLAG", SDTNone, [SDNPHasChain, SDNPOptInGlue, SDNPVariadic]>; let hasCtrlDep = 1, hasSideEffects = 1 in { def ADJCALLSTACKDOWN : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2), [(MYCallseqStart timm:$amt1, timm:$amt2)]>; def ADJCALLSTACKUP : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2),...

...> [SDNPHasChain, SDNPOptInGlue, > SDNPOutGlue, > SDNPVariadic]>; > def MYret : SDNode<"MYISD::RET_FLAG", SDTNone, > [SDNPHasChain, SDNPOptInGlue, > SDNPVariadic]>; > > let hasCtrlDep = 1, hasSideEffects = 1 in { > def ADJCALLSTACKDOWN : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2), > [(MYCallseqStart timm:$amt1, > timm:$amt2)]>; > def ADJCALLSTACKUP : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2), >...

...SDTypeProfile<0, -1, [SDTCisPtrTy<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...

Hi Matthijs, On Nov 3, 2008, at 9:05 AM, Matthijs Kooijman wrote: > > Am I doing something wrong here, or is tblgen mistaken? I think you're doing something that is beyond what tblgen is currently prepared for. But it's interesting :-). Having rd and RD have explicit chain operands and results sounds like the right thing to do. This is needed to prevent them from being reordered

...p the chain to both RD and MOVE. I think it might even join the two output chains together, not exactly sure about that. Not sure if this is really what I want, but it would work. So, the main thing needed is some way of telling that an instruction is chained, other than giving it a pattern. Using hasCtrlDep for this makes sense, but I'm afraid I won't be having the time nor expertise to implement this... I'd be glad to test it though :-) Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189...

...it isConvertibleToThreeAddress = 0; // see question 1 bit isCommutable = 0; // see rq1 below bit isTerminator = 0; // terminate what? A BB, A function, or the program bit isReMaterializable = 0; // ? bit isPredicable = 0; bit hasDelaySlot = 0; bit usesCustomDAGSchedInserter = 0; bit hasCtrlDep = 0; // ? bit isNotDuplicable = 0; // ? bit hasSideEffects = 0; bit mayHaveSideEffects = 0; // how is this different from has side effect? bit neverHasSideEffects = 1; Rq1: If I have a instruction 'add reg, imm' and don't have 'add imm, reg' I suppose the instruction i...