search for: instinfo

Maybe it's because I've got a lot of two machine operand instructions and have to rely on the tied-to constraint, but I'm seeing a lot of dead reg-to-reg copy instructions, e.g.: ori $3, $3, 0 (Cell SPU's version of reg-to-reg copy, looks a lot like PPC, no?) Is there any way I can detect when this occurs, or is there code where this detection takes place in the target to which

On 1/18/07, Scott Michel <scottm at rushg.aero.org> wrote: > Is there any way I can detect when this occurs, or is there code > where this detection takes place in the target to which I can > refer? have you implemented InstInfo::isMoveInstr to recognize those? The register allocator uses that to find copies it can remove. Andrew

I have some instructions that use a register as both an input and as the output. Is there a way to specify this constraint in the InstrInfo.td or will this have to be custom selected/lowered? Thanks -- Christopher Lamb christopher.lamb at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

I see in the x86 InstInfo.td the following for the INC instructions: def INC8r : I<0xFE, MRM0r, (ops GR8 :$dst, GR8 :$src), "inc{b} $dst", [(set GR8:$dst, (add GR8:$src, 1))]>; Which seem to have the same restriction that I'm trying to implement, but I don't understand how this e...

On Thu, 1 Mar 2007, Christopher Lamb wrote: > I see in the x86 InstInfo.td the following for the INC instructions: > > def INC8r : I<0xFE, MRM0r, (ops GR8 :$dst, GR8 :$src), "inc{b} $dst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Which seem to have the same restriction that I'm trying to implement, > but I don...

...n Defs The implicit defs don't participate much in the patterns. For the most part it's just read into CodeGenInstruction::ImplicitDefs and then GlobalISel gathers and adds them all at the end. I think I do see the code Gabriel is referring to though. GetNumNodeResults() has: if (InstInfo.HasOneImplicitDefWithKnownVT(CDP.getTargetInfo()) !=MVT::Other) ++NumDefsToAdd; and ultimately this VT gets into Types via UpdateNodeType(). I have no idea why this code does this as I don't really see why the VT matters to how you treat an implicit def. This code dates back to 2010 (r9...

On 9/17/2015 7:04 AM, Sky Flyer via llvm-dev wrote: > It seems like d0 is always 14! > I check it with ARMGenAsmMatcher.inc it was the same! > How is it possible? because it should give the same register value that > matches the underlying platform not any autogenerated value!? The returned number is the register id as defined in <YourTarget>GenRegisterInfo.inc. These numbers

...sics be pulled into the target directory ala Targets/MBlaze/MBlazeIntrinsics.td or Targets/NVPTX/NVPTXIntrinsics.td? > > > What's the best way to break up the patch? In the past I have divided it up > > into 4 patches: > > > > 1. Core Target files (*TargetMachine, *InstInfo, etc.) > > 2. Target specific passes > > 3. .td files > > 4. Configuration / Intrinsic additions > > > > Would something like this work? > > Any way that you can slices it to land it in stages would be preferred. Another major challenge will be to find someone...

...nto the target directory ala Targets/MBlaze/MBlazeIntrinsics.td or Targets/NVPTX/NVPTXIntrinsics.td? >> >>> What's the best way to break up the patch? In the past I have divided it up >>> into 4 patches: >>> >>> 1. Core Target files (*TargetMachine, *InstInfo, etc.) >>> 2. Target specific passes >>> 3. .td files >>> 4. Configuration / Intrinsic additions >>> >>> Would something like this work? >> >> Any way that you can slices it to land it in stages would be preferred. Another major challenge...

...msg/llvm-dev/BfUmfIWYRM8/6JGXQf1gCQAJ > > but, at the end, what is assigned to the Inst is, I suppose, the > register ID not the encoding! > > to be more clear, I do the followings: > *def D0 : TestReg<0x01, "d0">, DwarfRegNum<[0]>;* > > and then in InstInfo.td > *bits<6> Dr; > let Inst{5-3} = Dr{2-0};* > > assuming D0 is passed to $Dr, what I get in the encoding is 110, which I > think is the bit 0 to 2 of what is the returned value in the > TestGenAsmMatcher.inc. > I mean, at the end, Inst{5-3} is getting a value which is n...

...ala Targets/MBlaze/MBlazeIntrinsics.td or Targets/NVPTX/NVPTXIntrinsics.td? > >> > >>> What's the best way to break up the patch? In the past I have divided it up > >>> into 4 patches: > >>> > >>> 1. Core Target files (*TargetMachine, *InstInfo, etc.) > >>> 2. Target specific passes > >>> 3. .td files > >>> 4. Configuration / Intrinsic additions > >>> > >>> Would something like this work? > >> > >> Any way that you can slices it to land it in stages would be p...

...aze/MBlazeIntrinsics.td or Targets/NVPTX/NVPTXIntrinsics.td? >>>> >>>>> What's the best way to break up the patch? In the past I have divided it up >>>>> into 4 patches: >>>>> >>>>> 1. Core Target files (*TargetMachine, *InstInfo, etc.) >>>>> 2. Target specific passes >>>>> 3. .td files >>>>> 4. Configuration / Intrinsic additions >>>>> >>>>> Would something like this work? >>>> >>>> Any way that you can slices it to land it...

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,