search for: maystor

...ring for any intrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get TableGen to shut up about what it reasonably believes to be a mismatch between the properties of the intrinsic (which it conservatively believes to be mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction (which is correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0). Indeed, write-only without an ArgMemOnly property may well be useless at the IR level. If you think that there is a better way to explain the situation to TableGen, please...

...;> + >> +class STInst2<dag outs, dag ins, string asmstr, list<dag> pattern> >> + : InstHexagon<outs, ins, asmstr, pattern, "", ST, TypeST> { >> + bits<5> rd; >> + bits<5> rs; >> + bits<13> imm13; >> + let mayStore = 1; >> +} >> + >> +// SYSTEM Instruction Class in V4 can take SLOT0 only >> +// In V2/V3 we used ST for this but in v4 ST can take SLOT0 or SLOT1. >> +class SYSInst<dag outs, dag ins, string asmstr, list<dag> pattern> >> + : InstHexagon<outs, i...

...oad - Return true if this instruction could possibly read memory. /// Instructions with this flag set are not necessarily simple load /// instructions, they may load a value and modify it, for example. bool mayLoad() const { return Flags & (1 << MCID::MayLoad); } /// mayStore - Return true if this instruction could possibly modify memory. /// Instructions with this flag set are not necessarily simple store /// instructions, they may store a modified value based on their operands, or /// may not actually modify anything, for example. bool mayStore() const...

The new SUBREG target-independent instructions aren't getting mayLoad/mayStore flags set correctly. For example, in the generated X86GenInstrInfo.inc file, there is only one entry for INSERT_SUBREG: { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn'...

...ed. > > 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, we had to create two store insn classes: one which defined mayStore and one that didn't. The former was to be used when an insn had no pattern and the latter, when mayStore was implied in the pattern. If only TableGen wouldn't warn about non-conflicting attributes at least... -- Evandro Menezes Austin, TX emenezes at codeaurora.org Q...

On Mar 18, 2008, at 6:12 PM, Dan Gohman wrote: > The new SUBREG target-independent instructions aren't getting > mayLoad/mayStore flags set correctly. > > For example, in the generated X86GenInstrInfo.inc file, > there is only one entry for INSERT_SUBREG: > > { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, > OperandInfo107 }, // Inst #5 = INSERT_SUBREG > > THe sixth field...

...trinsic regardless the IR level attributes. >> >> As I explained in my reply to Philip, what I really need is a way to get TableGen to shut up about what it reasonably believes to be a mismatch between the properties of the intrinsic (which it conservatively believes to be mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction (which is correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0). > > I'm not sure what is the semantics of "hasSideEffects" at the MI level. I'm surprised we can consider correct that something that writes to memory...

...nd 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, we had to create two store insn classes: one which defined mayStore and one that didn't. The former was to be used when an insn had no pattern and the latter, when mayStore was implied in the pattern. > > If only TableGen wouldn't warn about non-conflicting attributes at least… That warning has been removed now, and you should be able to clean up...

Hi, I define a customized node with customized type. The job of this customized node is to move a value from one register class to another class. I find that if there is no use of the destination register, this node will be deleted from SDAG. For some reasons, I want to keep this node. So I attach mayStore attribute to this node and I hope it will not be deleted. However, it does not work like I assume. There must be something wrong. But I don't know it's because this trick does not work in theory or it's because my implementation is wrong. def MoveTy : SDTypeProfile<1, 1, []>; d...

...tern(s?) field, > TableGen won't know it needs the chain. Tim, Correct, the instruction has no pattern of its own. > > There's a big comment just above the test about how the current > situation is rather broken. I'm currently inclined to add a check for > mayLoad and mayStore at that point in TableGeni (see patch), but was > waiting until I could give tests and justification on the list before > submitting it. Thanks for sending this! As far as a long-term solution, would it be better to update TableGen with this logic instead of putting this in ISel? Also, we s...

Hi, I'd like to draw your attention to http://reviews.llvm.org/D18291, in which I propose a new intrinsic property for intrinsics that are lowered to instructions that mayStore, but are neither mayLoad nor hasSideEffects. This is relevant for AMDGPU, where we have store instructions that don't operate on pointers. The codegen backend understands these perfectly well as stores, and so we can enable better scheduling decisions than if we forced these instruction to...

...at I'm under these constriants but that's the way it is, unfortunately. >> The change requires that live interval analysis be able to determine >> whether and instruction is a load and whether an instruction writes to >> memory. > > Just use MI->mayLoad(), MI->mayStore(). Does this also account for arithmetic instructions with memops? These interfaces didn't exist in 2.9. > [And live interval analysis shouldn't be involved in remat these days.] Ok, I'm working off 2.9 so I'll have to update for trunk. That's no problem. >> The...

...tion of the Pat gets a chain. So if your QVLFDXb instruction doesn't set the Pattern(s?) field, TableGen won't know it needs the chain. There's a big comment just above the test about how the current situation is rather broken. I'm currently inclined to add a check for mayLoad and mayStore at that point in TableGeni (see patch), but was waiting until I could give tests and justification on the list before submitting it. Tim. -------------- next part -------------- diff --git a/utils/TableGen/DAGISelMatcherGen.cpp b/utils/TableGen/DAGISelMatcherGen.cpp index 2ac7b87..4acd209 100644...

...it needs the chain. > > Tim, > > Correct, the instruction has no pattern of its own. > > > > > There's a big comment just above the test about how the current > > situation is rather broken. I'm currently inclined to add a check > > for mayLoad and mayStore at that point in TableGeni (see patch), > > but was waiting until I could give tests and justification on the > > list before submitting it. > > Thanks for sending this! Please ignore this statement: > As far as a long-term solution, would it be > better to update TableGe...

...> > > > Correct, the instruction has no pattern of its own. > > > > > > > > There's a big comment just above the test about how the current > > > situation is rather broken. I'm currently inclined to add a check > > > for mayLoad and mayStore at that point in TableGeni (see patch), > > > but was waiting until I could give tests and justification on the > > > list before submitting it. > > > > Thanks for sending this! > > Please ignore this statement: > > As far as a long-term solution, would...

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

hi Tim,guys, it was regarding splitting 16-bit ADDC to two 8-bit ADDC+ADDE. the 8-bit ADDE instruction is defined as: let Constraints="$dst=$op0",mayStore=1, hasSideEffects=0,neverHasSideEffects=1 in def ADDErm: myInstr <0x0, (outs Intregs:$dst) (ins Intregs:$op0,MEMi:$op1), "", [set IntRegs:$dest (adde IntRegs:$op0, (load ADDRi:$op1))] > very unlucky, this instruction failed. in the generated match table, there was flag OPFL_Chai...

...ur time. > I plan to send these up ASAP but I want to solicit a bit of guidance > first. > > The change requires that live interval analysis be able to determine > whether and instruction is a load and whether an instruction writes to > memory. Just use MI->mayLoad(), MI->mayStore(). [And live interval analysis shouldn't be involved in remat these days.] > The remat code itself identifies load instructions and checks to see > whether it interferes with any instructions that write to memory. How does that affect compile time? > Finally, are MachineMemOperand...

...ng mayLoad flag *** which comes from: // Check the MachineMemOperands for basic consistency. for (MachineMemOperand *Op : MI->memoperands()) { if (Op->isLoad() && !MI->mayLoad()) report("Missing mayLoad flag", MI); if (Op->isStore() && !MI->mayStore()) report("Missing mayStore flag", MI); } The MI is ARM::tBL, and it doesn't have mayLoad set, which hits the assert in MachineVerifier, since it still has memory operands attached by foldMemoryOperand. I have attached patch (changes to foldMemoryOperand), that checks if the...

...ld be there. > > > I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitions when some properties are inferred, but only half the time. Yes, please. This does get a bit more complicated for properties like mayLoad, mayStore and such, but I still like requiring them to be explicit, personally. When there's a pattern on the instruction, we can check for semantic mismatches and throw an error if we find one. > > We can still use any patterns to emit TableGen warnings. If an instruction has a sideeffecting pa...