search for: hasunmodeledsideeffect

...check offsets and sizes of the + // accesses. + MachineMemOperand *MMOa = *MIa->memoperands_begin(); + MachineMemOperand *MMOb = *MIb->memoperands_begin(); + const Value *VALa = MMOa->getValue(); + const Value *VALb = MMOb->getValue(); + if (VALa == VALb && + !MIa->hasUnmodeledSideEffects() && !MIb->hasUnmodeledSideEffects() && + !MIa->hasOrderedMemoryRef() && !MIb->hasOrderedMemoryRef()) { + int OffsetA = MMOa->getOffset(), OffsetB = MMOb->getOffset(); + int WidthA = MMOa->getSize(), WidthB = MMOb->getSize(); + int LowOffs...

...vide by zero instruction out of the loop. Clearly this pass needs to be made aware that this is not safe. The current test in the MachineLICM is as follows: // Ignore stuff that we obviously can't hoist. if (TID.mayStore() || TID.isCall() || TID.isReturn() || TID.isBranch() || TID.hasUnmodeledSideEffects()) return false; Setting hasSideEffects = 1 seems to work, but I'm not sure if that's the intended use of this flag. I notice that divide / remainder instructions for other architectures are not marked in this way. Also it is also pessimistic: if the divisor is know to be non zero...

...t; > > > Thanks for sending this! > > Please ignore this statement: > > As far as a long-term solution, would it be > > better to update TableGen with this logic instead of putting this in > > ISel? > > -Hal > > > Also, we should probably include hasUnmodeledSideEffects along > > with mayLoad and mayStore. 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)? Thanks again, Hal > > > > -Hal > >...

...eGeni (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 should probably include hasUnmodeledSideEffects along with mayLoad and mayStore. -Hal > > Tim. -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

> 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* at the moment. I'm not sure how I missed it before. Unless anyone comes up with a better idea (or just a r...

...fication 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 with this logic instead of putting this in > ISel? -Hal > Also, we should probably include hasUnmodeledSideEffects along > with mayLoad and mayStore. > > -Hal > > > > > Tim. > > > -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

...> > 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 is not "having side effects". Answer to myself, I finally found the MI API (thanks Matthias), and it is called hasUnmodeledSideEffects. I think the "unmodeled" part of the name is important here :) Here is the doxygen: /// \brief Return true if this instruction has side /// effects that are not modeled by other flags. This does not return true /// for instructions whose effects are captured by: /// /// 1. T...

...r which cannot be // moved safely. if (TargetRegisterInfo::isVirtualRegister(DefReg) && MI.getOperand(0).getSubReg() && MI.readsVirtualRegister(DefReg)) return false; // Avoid instructions obviously unsafe for remat. if (MI.isNotDuplicable() || MI.mayStore() || MI.hasUnmodeledSideEffects()) return false; // Don't remat inline asm. We have no idea how expensive it is // even if it's side effect free. if (MI.isInlineAsm()) return false; } We have following doubts and require guidance and suggestion to move ahead: 1. Is the approach we are following feasible?...

On 19.03.2016 16:25, Mehdi Amini wrote: > Hi, > > Can you elaborate what is the impact at the IR level? > If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize 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

...t; 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* at the moment. I'm not sure how I missed it > before. > > Unless anyone comes...

On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > Working on a target I added this pattern: > > def : Pat<(v4i64 (load xoaddr:$src)), > (QVFCTIDb (QVLFDXb xoaddr:$src))>; > > I'd like to fix this so that it works correctly: the TokenFactor > inputs should be attached to all inner-most instructions. I'm guessing > this is somewhere in

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

...X86::INSERTPSrr : + return isValidINSERTPS(MI); + } + + llvm_unreachable(0); +} + +bool X86FoldRedundantInserts::SimplifyBlock(MachineBasicBlock &MBB) { + bool Changed = false; + MachineBasicBlock::iterator I = MBB.end(), E = MBB.begin(); + + while (I != E) { + --I; + if (I->hasUnmodeledSideEffects()) { + // Invalidate the Map. + Candidates.clear(); + continue; + } + + if (isValidCandidate(*I)) { + // Add this entry to the Candidates map. + unsigned RegDef = I->getOperand(0).getReg(); + Candidates.insert(std::make_pair(RegDef, I)); + continue; +...

...nition, then the optional > definition is always the last register operand in the sequence. > > Note that some of the information accessible from the MCInstrDesc is always > valid for MCInst. For example: implicit register defs, implicit register uses > and 'MayLoad/MayStore/HasUnmodeledSideEffects' opcode properties still apply to > MCInst. The tool knows about this, and uses that information during its > analysis. You just made a very strong argument for building the MachineInstrs before running mca. So I wonder why you didn’t do that. > What to do next > ---------------...

...pecifies an optional definition, then the optional definition is always the last register operand in the sequence. Note that some of the information accessible from the MCInstrDesc is always valid for MCInst. For example: implicit register defs, implicit register uses and 'MayLoad/MayStore/HasUnmodeledSideEffects' opcode properties still apply to MCInst. The tool knows about this, and uses that information during its analysis. What to do next --------------- The source code has been uploaded for review on phabricator at this link: https://reviews.llvm.org/D43951. The review covers two patches: A firs...

...n the optional >     definition is always the last register operand in the sequence. > > Note that some of the information accessible from the MCInstrDesc is > always > valid for MCInst. For example: implicit register defs, implicit > register uses > and 'MayLoad/MayStore/HasUnmodeledSideEffects' opcode properties still > apply to > MCInst. The tool knows about this, and uses that information during its > analysis. > > What to do next > --------------- > The source code has been uploaded for review on phabricator at this > link: https://reviews.llvm.org/D4395...

...on, then the optional > definition is always the last register operand in the sequence. > > Note that some of the information accessible from the MCInstrDesc is always > valid for MCInst. For example: implicit register defs, implicit register > uses > and 'MayLoad/MayStore/HasUnmodeledSideEffects' opcode properties still > apply to > MCInst. The tool knows about this, and uses that information during its > analysis. > > What to do next > --------------- > The source code has been uploaded for review on phabricator at this link: > https://reviews.llvm.org/D43951....

...on, then the optional > definition is always the last register operand in the sequence. > > Note that some of the information accessible from the MCInstrDesc is always > valid for MCInst. For example: implicit register defs, implicit register > uses > and 'MayLoad/MayStore/HasUnmodeledSideEffects' opcode properties still > apply to > MCInst. The tool knows about this, and uses that information during its > analysis. > > > You just made a very strong argument for building the MachineInstrs before > running mca. So I wonder why you didn’t do that. > > What to d...