search for: mayload

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 d...

Hi Quentin, I get following error from MachineVerifier: # End machine code for function f. *** Bad machine code: Missing 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()...

...lize the lowering 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 Tab...

these are supposed for any instruction which could possible read/write memory? (btw, should be canload or canstore in that case :) ) this does not seem to be consistent with their use in TD files. /// mayLoad - 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); } /// may...

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 six...

I made a small change to my target and them tried to recompile it. The following error showed up: error: Pattern doesn't match mayLoad = 0 A little bit of searched revealed that it came from here: https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/CodeGenDAGPatterns.cpp#L2861 Unfortunately I can't understand what it means. Can someone help me out? -- Rail Shafigulin Software Engineer Esencia Technologies ------...

...t; > 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 solu...

...ng 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). > > I'm not sure what is the semantics of "hasSideEffects" at the MI level. I'm surprised we can consider correct that something that writ...

...few people to better understand the tablegen descriptions of instructions and patterns in LLVM's backend and looking at x86's pretty heavily, I have some questions: 1) Are there instruction definition flags that are really just "when needed"? I'm thinking of things like "mayLoad" which is really alarmingly missing from a bunch of instructions in x86 which load. Is this OK? Is this a bug, or just suboptimal? 2) Are all of the flags in Target.td (lines 356 - 381) the "recommended" set? Are any of them no longer really important to mark? 3) It would be really...

I'm seeing a bunch of new warnings... Warning: mayLoad flag explicitly set on instruction 'VLD1d16' but flag already inferred from pattern. Warning: mayLoad flag explicitly set on instruction 'VLD1d32' but flag already inferred from pattern. Warning: mayLoad flag explicitly set on instruction 'VLD1d64' but flag already inf...

> I also had to include II.canFoldAsLoad to make this work 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*...

On Tue, Nov 17, 2015 at 11:15 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 11/17/2015 12:26 PM, Rail Shafigulin wrote: > >> >> I tried setting >> let mayLoad = 1 { >> class InstrLD .... { >> } >> } >> >> But that didn't seem to work. When I looked at the debug output the >> latency for the load instruction was set to 1. >> >> However when I changed load itinerary description in the schedule to &...

...don't like that 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 probl...

...tency: > > /// Return the default expected latency for a def based on it's opcode. > unsigned TargetInstrInfo::defaultDefLatency( > const MCSchedModel &SchedModel, const MachineInstr *DefMI) const { > if (DefMI->isTransient()) > return 0; > if (DefMI->mayLoad()) > return SchedModel.LoadLatency; > if (isHighLatencyDef(DefMI->getOpcode())) > return SchedModel.HighLatency; > return 1; > } > > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foun...

...December 30, 2013 2:29:50 PM > Subject: Re: [LLVMdev] Random question about the x86 backend (and backends in general I suppose) > > > > I can't speak directly to the questions themselves, but I'll ask a > couple back. When you say that some instructions are missing > mayLoad, do these instructions have patterns? Tablegen can infer > mayLoad/mayStores/hasSideEffects from patterns so it doesn't always > need to be listed explicitly in the td files. Having recently audited these flags in the PowerPC backend, I highly recommend looking at these from the *GenInst...

...set the Pattern(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...

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 hasSideEffects. In a per...

...ence, but features like this work best when they work all the time. If all instructions had patterns, and we could accurately infer properties, it wouldn't be a problem. > Won't this hugely bloat the .td files? Not really, TableGen has a fairly convenient syntax for bulk flagging: let mayLoad = 1 in { let Defs = [AL,EFLAGS,AX], Uses = [AX] in def DIV8m : I<0xF6, MRM6m, (outs), (ins i8mem:$src), // AX/[mem8] = AL,AH "div{b}\t$src", [], IIC_DIV8_MEM>; let Defs = [AX,DX,EFLAGS], Uses = [AX,DX] in def DIV16m : I<0xF7, MRM6m, (outs), (ins i16mem:$src), /...

On Sun, 24 Jun 2012 10:18:00 +0100 Tim Northover <t.p.northover at gmail.com> wrote: > > I also had to include II.canFoldAsLoad to make this work 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 a...

...to tackle right now. Why am I pushing for IntrWriteOnly? I suspect the merely IntrWriteOnly without a functional ArgMemOnly does not provide a lot of opportunity for optimization at the IR level. However, the codegen backend does understand the resulting hardware instructions, which are marked mayLoad = 0, mayStore = 1, hasSideEffects = 0. Having mayLoad = 0 and hasSideEffects = 0 makes a difference for instruction scheduling. If you try to map the intrinsic as-is, without IntrWriteOnly, onto such hardware instructions, TableGen will (correctly) complain about a mismatch of mayLoad and hasS...