similar to: [LLVMdev] Multi-Instruction Patterns

On Sep 24, 2008, at 10:16 AM, Chris Lattner wrote: > On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >>> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >>> the super-register / sub-register relationship. >> >> I don't understand the problem with subregs

On Wednesday 24 September 2008 02:10, Evan Cheng wrote: > > I wrote a pattern that looks something like the above in form, but how > > do I tell the selection DAG to prefer my pattern over another that > > already exists. I can't easily just disable that other pattern > > because > > it generates Machine Instruction opcode enums that are assumed to be > >

Chris Lattner wrote: > On Sep 23, 2008, at 11:26 AM, David Greene wrote: > >> Are there any examples of using tablegen to generate multiple machine >> instructions from a single pattern? Or do these cases always have >> to be >> manually expanded? > > PPC has a bunch of examples, for example: > > // Arbitrary immediate support. Implement in terms of

On Sep 24, 2008, at 11:34 AM, Evan Cheng wrote: > > On Sep 24, 2008, at 10:16 AM, Chris Lattner wrote: > >> On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>>> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >>>> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >>>> the super-register / sub-register

On Sep 23, 2008, at 7:17 PM, David Greene wrote: > Chris Lattner wrote: >> On Sep 23, 2008, at 11:26 AM, David Greene wrote: >> >>> Are there any examples of using tablegen to generate multiple >>> machine >>> instructions from a single pattern? Or do these cases always have >>> to be >>> manually expanded? >> >> PPC has a

On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >> the super-register / sub-register relationship. > > I don't understand the problem with subregs here. Is it just a > naming issue? That can be solved by introducing

On Sep 24, 2008, at 9:15 AM, David Greene wrote: > >> 1. Treat these instructions as cross register class copies. The src >> and dst classes are different (VR128 and FR32) but "compatible". > > This seems reasonable. > >> 2. Model it as extract_subreg which coalescer can eliminate. >> >> #2 is conceptually correct. The problem is 128 bit XMM0 is

On Sep 23, 2008, at 11:26 AM, David Greene wrote: > Are there any examples of using tablegen to generate multiple machine > instructions from a single pattern? Or do these cases always have > to be > manually expanded? PPC has a bunch of examples, for example: // Arbitrary immediate support. Implement in terms of LIS/ORI. def : Pat<(i32 imm:$imm), (ORI (LIS (HI16

Are there any examples of using tablegen to generate multiple machine instructions from a single pattern? Or do these cases always have to be manually expanded? -Dave

On Wednesday 24 September 2008 12:20, Evan Cheng wrote: > > I'm not seeing how this is "conceptually correct." It's a vector > > extract, not > > a subregister. It's just that we want to reuse the same register. > > It is though. Sub-register is a machine specific concept. It means > vector_extract can be modeled as subreg_extract on this

Hi, I noticed a bunch of psuedo instructions used for creation of constants without generating loads. e.g. pxor xmm0, xmm0 Here is an example of what i am referring to snipped from X86InstrSSE.td: def FsFLD0SS : I<0xEF, MRMInitReg, (outs FR32:$dst), (ins), "", [(set FR32:$dst, fp32imm0)]>, Requires<[HasSSE1]>, TB, OpSize; My question is

Is it legal to do something like a !strconcat on a non-string entity? That is, is there some operation that will let me do this (replace SOME_CONCAT with an appropriate operator): (WARNING! Hacked-up tablegen ahead!) multiclass sse_fp_binop_bitwise_rm<bits<8> opc, string OpcodeStr, SDNode OpNode> { // Vector operation emulating scalar (fp)

On Jul 26, 2012, at 10:28 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >>> What happens if the result of the above pattern using COPY_TO_REGCLASS >>> is spilled? Will we get a 64-bit store or a 128-bit store? >> >> This behavior isn't affected by the change. FR64 registers are spilled >> with 64-bit

On Mar 23, 2009, at 5:56 PM, David Greene wrote: > Is it legal to do something like a !strconcat on a non-string > entity? That > is, is there some operation that will let me do this (replace > SOME_CONCAT with > an appropriate operator): I don't get it, can you try a simpler example on me? :) -Chris > > > (WARNING! Hacked-up tablegen ahead!) > >

Yes, Another reason this is useful is for register-type specific representations of said register. For example, all my registers are 128bit vector registers, however, if I am only dealing with 32 bit vector registers, I can add write/read masks that tell the underlying hardware not to work on the whole register, but just a subset of the components. 32bit scalar mov: mov r1.x___, r0.x000 64bit

Hello, I have studied register allocation in theoretical aspects and exploring the same in the implementation level. I need a minimal testcase for register spilling to analyze spilling procedure in llvm. I tried with a testcase taking 20 variables but all the 20 variables are getting stored in the stack using %rbp. Maybe my live variable analysis is wrong. Please help me with a minimal testcase

On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > To my knowledge, I don't think there is an easy way to get the MVT > information from a MachineOperand. Why do you need it for? In my See the thread I started on this very topic. Spilling is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a >

On Tue, Feb 10, 2009 at 8:27 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Bill, > Sorry if I wasn't clear enough. I wasn't referring to multiclass's that > define other classes, but with using patterns inside of a multiclass to > reduce redundant code. > For example: > multiclass IntSubtract<SDNode node> > { > def _i8 : Pat<(sub

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> What happens if the result of the above pattern using COPY_TO_REGCLASS >> is spilled? Will we get a 64-bit store or a 128-bit store? > > This behavior isn't affected by the change. FR64 registers are spilled > with 64-bit stores, and VR128 registers are spilled with 128-bit > stores. > > When the

All, I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them. These sub-registers are special, they are only mentioned here: let CompositeIndices = [(sub_ss), (sub_sd)] in { def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; def