search for: isinternalread

...g is implied by the use of the register before the '=', unless it's implicit. - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by the instruction description. (I believe that's true in all cases, but I'm not 100% sure). - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like 'implicit', 'undef', 'kill', 'dead' are used before the register e.g. 'undef %rax', 'implicit-def kill %eflags'. I don't have a syntax for the SubReg_TargetFlags at the moment. Alex > > - .... > >...

...after regalloc. > > We do not want to see any Bundle instructions prior to regalloc. So a preRA scheduler should not call finalizeBundles. It can create bundles simply by setting the isInsideBundle flag on MachineInstrs. If you allow internal register dependencies you would also need to set isInternalRead on those MachineOperands. > Thanks, this information is really helpful. One question, though: If preRA bundles can't have Bundle instructions, then how does the register allocator determine the boundaries between bundles? -Tom

...;s running after regalloc. We do not want to see any Bundle instructions prior to regalloc. So a preRA scheduler should not call finalizeBundles. It can create bundles simply by setting the isInsideBundle flag on MachineInstrs. If you allow internal register dependencies you would also need to set isInternalRead on those MachineOperands. -Andy

...s set. /// /// This refers to reading the register value from before the current /// instruction or bundle. Internal bundle reads are not included. bool readsReg() const { assert(isReg() && "Wrong MachineOperand accessor"); return !isUndef() && !isInternalRead() && (isUse() || getSubReg()); } I don't get why we automatically should get an implicit use just because we are writing a subreg. Since Reg5:lo16 is defined with Reg5:lo16<def> = Reg1 isUndef() will return false and getSubReg() true, and thus readsReg() true an...

On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > Tom, > > I do not have your call stack, but packetizer calls > ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is > the first time you use the new MI sched infrastructure (like your target has > not implemented misched yet) there might be some work needed to implement > couple target

...e the '=', >> unless it's implicit. >> - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by >> the instruction description. (I believe that's true in all cases, but I'm >> not 100% sure). >> - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like >> 'implicit', 'undef', 'kill', 'dead' are used before the register e.g. >> 'undef %rax', 'implicit-def kill %eflags'. >> I don't have a syntax for the SubReg_TargetFlags at the moment. > > Since t...

...e bundle: { P0 = cmp.eq(R2,#4) if (!P0) R5 = #5 if (P0.new) R3 = memw(R4) } This Hexagon bundle reads both the P0 predicate register defined inside the bundle (P0.new) and the value defined outside the bundle (!P0). We need to support this. I propose that we add a new MachineOperand flag, IsInternalRead, to represent this. The flag will mean "This operand is reading a value defined within the same instruction/bundle, not a value from outside the instruction/bundle." The register allocator will treat the <internal> flag almost exactly like it currently treats <undef>, but th...

Hi Sergei, Jakob, Thanks for your comments ! On 07/06/2012 20:41, Sergei Larin wrote: > > Jakob, > > Please see my comments below. Hope this helps. > > Sergei > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > *From:*Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > *Sent:* Thursday, June 07, 2012 1:02 PM > *To:* Sergei

Hi again! On 08/06/2012 17:11, Ivan Llopard wrote: > Hi Sergei, Jakob, > > Thanks for your comments ! > > On 07/06/2012 20:41, Sergei Larin wrote: >> >> Jakob, >> >> Please see my comments below. Hope this helps. >> >> Sergei >> >> -- >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. >>

Hi all, I would like to propose a text-based, human readable format that will be used to serialize the machine level IR. The major goal of this format is to allow LLVM to save the machine level IR after any code generation pass and then to load it again and continue running passes on the machine level IR. The primary use case of this format is to enable easier testing process for the code

Machine Instruction Bundle in LLVM Hi all, There have been quite a bit of discussions about adding machine instruction bundle to support VLIW targets. I have been pondering what the right representation should be and what kind of impact it might have on the LLVM code generator. I believe I have a fairly good plan now and would like to share with the LLVM community. Design Criteria 1. The