search for: maystore

Displaying 20 results from an estimated 87 matches for "maystore".

2016 Mar 21
3
New intrinsic property IntrOnlyWrite
...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...
2012 Apr 19
0
[LLVMdev] Target Dependent Hexagon Packetizer patch
...;> + >> +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, in...
2011 Oct 01
0
[LLVMdev] mayload and maystore?
...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 {...
2008 Mar 19
2
[LLVMdev] SUBREG instructions and mayLoad/mayStore/etc.
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'...
2012 Aug 22
2
[LLVMdev] Let's get rid of neverHasSideEffects
...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 Qu...
2008 Mar 19
0
[LLVMdev] SUBREG instructions and mayLoad/mayStore/etc.
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...
2016 Mar 22
1
New intrinsic property IntrOnlyWrite
...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 i...
2012 Aug 24
0
[LLVMdev] Let's get rid of neverHasSideEffects
...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 y...
2016 Feb 01
2
TableGen customized node with mayStore attribute is deleted if there is no use
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, []>; de...
2012 Jun 24
2
[LLVMdev] Complex load patterns and token factors
...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 sh...
2016 Mar 19
4
New intrinsic property IntrOnlyWrite
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...
2012 Feb 24
2
[LLVMdev] [RFC] Remat Enhancements
...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 r...
2012 Jun 23
0
[LLVMdev] Complex load patterns and token factors
...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 -...
2012 Jun 24
0
[LLVMdev] Complex load patterns and token factors
...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 TableGen...
2012 Jun 24
2
[LLVMdev] Complex load patterns and token factors
...> > > > 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 i...
2012 Jun 23
2
[LLVMdev] Complex load patterns and token factors
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
2014 Apr 26
2
[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc
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_Chain...
2012 Feb 23
0
[LLVMdev] [RFC] Remat Enhancements
...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 MachineMemOperands...
2020 Sep 10
2
Change prototype for TargetInstrInfo::foldMemoryOperandImpl
...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...
2012 Aug 21
0
[LLVMdev] Let's get rid of neverHasSideEffects
...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 pat...