similar to: [LLVMdev] Pesudo X86 instructions used for generating constants

Hi all, I think I found a bug in LLVM 3.0: When compiling for a target without SSE2 support, there were some 128-bit PXOR instructions in the generated code. I traced it down to the following definition in X86InstrSSE.td: def FsFLD0SS : I<0xEF, MRMInitReg, (outs FR32:$dst), (ins), "", [(set FR32:$dst, fp32imm0)]>,

On Fri, Jan 20, 2012 at 2:47 PM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I think I found a bug in LLVM 3.0: When compiling for a target without > SSE2 support, there were some 128-bit PXOR instructions in the generated > code. > > I traced it down to the following definition in X86InstrSSE.td: > >   def FsFLD0SS : I<0xEF, MRMInitReg,

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

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 Tuesday 24 March 2009 10:43, Chris Lattner wrote: > 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

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!) > >

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 Wed, September 24, 2008 12:10 am, Evan Cheng wrote: > > 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

Hi, I'm looking at scalar and packed instructions in X86. The instruction VCOMISS is scalar. May I remove SSEPackedSingle/SSEPackedDouble domain from it? defm VUCOMISS : sse12_ord_cmp<0x2E, FR32, X86cmp, f32, f32mem, loadf32, "ucomiss", SSEPackedSingle>, TB, VEX, VEX_LIG; defm VUCOMISD : sse12_ord_cmp<0x2E, FR64, X86cmp, f64,

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

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 GPRI8:$src0, GPRI8:$src1), (ADD_i8 GPRI8:$src0, (NEGATE_i8 GPRI8:$src1))>; def _i32 : Pat<(sub

Hi all, I have a bunch of new registers set up in X86RegisterInfo.td, the important part being def PR128 : RegisterClass<"X86", [i128], 128, (sequence "POI%u", 0, 7)>; def VR128 : RegisterClass<"X86", [v4f32, v2f64, v16i8, v8i16, v4i32, v2i64], 128, (add PR128, FR32)>; I have an entry in

On Aug 25, 2011, at 4:17 PM, Cameron McInally wrote: > Hey guys, > > Are spills/reloads of AVX registers using aligned stores/loads? Yes. > I can't > seem to find the code that aligns the stack slots to 32-bytes. Could > someone point me in the right direction? The register class has 256-bit spill alignment: def VR256 : RegisterClass<"X86", [v32i8, v16i16,

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 Jun 11, 2009, at 2:01 PM, David Greene wrote: > On Thursday 11 June 2009 12:28, Chris Lattner wrote: >>> >>> Yes. I want TableGen to be able to infer lots of stuff >>> programmatically. >>> This helps tremendously when specifying things like, oh, AVX. :) >> >> I don't see how this relates to regex's, and really don't want to

Here's the big RFC. A I've gone through and designed patterns for AVX, I quickly realized that the existing SSE pattern specification, while functional, is less than ideal in terms of maintenance. In particular, a number of nearly-identical patterns are specified all over for nearly-identical instructions. For example: let Constraints = "$src1 = $dst" in { multiclass

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

Chris Lattner wrote: > However, I don't see any reason to base this off of strings. Instead > of passing down "f32" as a string, why not do something like this > pseudo code: > > class X86ValueType { > RegisterClass RegClass; > ... > } > > def X86_f32 : X86ValueType { > let RegClass = FR32; > ... }; > def X86_i32 :

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