search for: jolesen

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

On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1, (EXTR...

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chad Rosier" <mcrosier at codeaurora.org>, "Jakob Stoklund Olesen" <jolesen at apple.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, November 21, 2013 2:36:06 PM > Subject: Re: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > > BTW I managed to get around this problem by flagging...

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> If the 128-bit register is not ever used as a 128-bit register, >> shouldn't the coalescer pick the 64- or 32-bit register? > > That optimization is not currently implemented for sub-registers. For > example, if you create a GR64 virtual registe...

Jakob Stoklund Olesen <jolesen at apple.com> writes: > On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: > >> For example, I want to be able to do this: >> >> defm MOVH : >> vs1x_fps_binary_vv_node_rmonly< >> 0x16, "movh", undef, 0, >> // rr >>...

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

Jakob Stoklund Olesen <jolesen at apple.com> writes: > 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 XMM1: Register<"xmm1">, DwarfRegN...

On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: > For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], > // rm > [(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, >

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

On Oct 6, 2011, at 12:42 PM, David A. Greene wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: >> >>> For example, I want to be able to do this: >>> >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >&g...

Jakob Stoklund Olesen <jolesen at apple.com> writes: > I think the for loops have merit, but not the way you want to use them. > > Some target descriptions have many sequential definitions, for example PowerPC/PPCRegisterInfo.td: > > // Vector registers > def V0 : VR< 0, "v0">, DwarfRegNum...

On Oct 7, 2011, at 2:23 PM, David A. Greene wrote: >> As repeated many times on this thread, the most common operation that >> a .td file must support is looking up an instruction and figuring out >> what its properties are and where they came from. > > Ok. What properties are most important to look up? I have found it > really easy to just run "tblgen

On Oct 6, 2011, at 10:25 AM, David A. Greene wrote: > greened at obbligato.org (David A. Greene) writes: > >> So here's why I think the for loop proposal can't be a preprocessing >> phase. Down in the guts of this I fundamentally need to be able to do >> this: >> >> multiclass blah<list<int> Values> { >> for v = Values { >>

On Oct 6, 2011, at 10:01 AM, David A. Greene wrote: > I want to be able to use #..# pasted stuff in a variety of contexts. > For example: > > multiclass blah<string intr> { > for prefix = [<empty>, Vx, Vy] { > for suffix = [ps, pd] { > def #prefix#ADD#suffix# : ProcessSomePattern< > [(set RegClass:$dst,

Bill Wendling <wendling at apple.com> writes: > On Oct 7, 2011, at 12:03 PM, David A. Greene wrote: >> >>>> How about a less massive and complicated scheme? I think we can >>>> make some good improvements to the current spec that will help >>>> with the MIC work. >>> >>> I'd like to defer MIC work until it's

On Oct 10, 2011, at 7:21 AM, David A. Greene wrote: > Bill Wendling <wendling at apple.com> writes: > >> As the release enginerd, I would encourage you to hold off any changes >> to TableGen until after Friday, if they can wait. :-) Of course, Jakob >> gets the final say on whether they go in or not. > > If I can get the for loop done, it would benefit all

Jakob Stoklund Olesen <jolesen at apple.com> writes: > On Oct 10, 2011, at 7:21 AM, David A. Greene wrote: > >> Bill Wendling <wendling at apple.com> writes: >> >>> As the release enginerd, I would encourage you to hold off any changes >>> to TableGen until after Friday, if they can...

greened at obbligato.org (David A. Greene) writes: > So here's why I think the for loop proposal can't be a preprocessing > phase. Down in the guts of this I fundamentally need to be able to do > this: > > multiclass blah<list<int> Values> { > for v = Values { > def DEF#v : base_class<v>; > } > } > > Will that work? Is the for

...order to emit "la $4,ADDR" instead of lui followed by addiu to load the data address, could you advise what is proper way to revise td files in the MIPS target? Why? -eric ------------------------------ Message: 4 Date: Wed, 05 Oct 2011 17:04:58 -0700 From: Jakob Stoklund Olesen <jolesen at apple.com> Subject: [LLVMdev] TableGen and Greenspun To: llvmdev List <llvmdev at cs.uiuc.edu> Message-ID: <A19B9B72-5673-4463-AF0D-AC286D5EBD5D at apple.com> Content-Type: text/plain; CHARSET=US-ASCII The TableGen language seems to be growing Lisp macros from two different direc...

On Jan 9, 2012, at 10:00 AM, Jakob Stoklund Olesen wrote: > > On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > >> I'll explain what we see in the code. >> 1. The caller saves XMM registers across the call if needed (according to DEFS definition). >> YMMs are not in the set, so caller does not take care. > > This is not how the register allocator