The changes in whirl2.p (the enhancement on OPR_SELECT and changes in CG EXP phase) look fine to me.
2011/6/29 Mathew, Pallavi <pallavi.mat...@amd.com>: > Hi Fred, Mei and CG gatekeeper, > Can you please take a look at the attached revised and re-tested patches that > introduce a framework for vectorization of IF-statements? > > whirl3.p: revised patch that extends the supported types of OPR_SELECT to > include V16I1 (to support generation of blend instruction). The patch also > extends rtype/desc of OPR_EQ to include V16I8. > vectorizer3.p: the only update to this patch is that the use of OPR_BLEND is > replaced with OPR_SELECT. > > Thanks. > Pallavi > > -----Original Message----- > From: Fred Chow [mailto:frdc...@gmail.com] > Sent: Wednesday, June 15, 2011 10:56 PM > To: Mathew, Pallavi > Cc: open64-devel@lists.sourceforge.net > Subject: Re: [Open64-devel] Code review request for vectorizer patch [LNO] > [CG] > > I see no reason why SELECT cannot be used to represent BLEND by > extending its supported types. New operators should be avoided whenever > possible, to avoid proliferation of variants of WHIRL. Following is my > enhancement of the definition of SELECT, assuming V16 is what you need now: > > SELECT res=i,f,V16 desc=B,i,V16 [H-VL] > Both Kid 1 and Kid 2 must have res as their result types. If Kid 0 is > not type V16, return Kid 1 if Kid 0 evaluates to true; otherwise, return > Kid 2. If Kid 0 is type V16, both Kids 1 and 2 must also be type V16, > and the resulting V16 vector has its elements selected from the > corresponding elements of either Kid 1 or 2 based on their corresponding > boolean elements in Kid 0. The evaluation of both Kids 1 and 2 can be > performed regardless of the value of Kid 0. Converting an if statement > to this operation is tantamount to speculation if Kid 1 or 2 are > expressions. > > Fred > > On 06/15/2011 04:45 PM, Mathew, Pallavi wrote: >> Hi Fred, >> Couple of points in favor of the new operator: >> 1. Semantically the BLEND operation is like a concatenation operation >> combining components from separate sources while the SELECT operation >> selects one or the other source. I realize though that this can be argued >> against by considering blend as a packed or vectorized select. >> 2. While the SELECT operation places restriction on the result type of its >> kids (kid1/2 must match the result type of select and kid0 must evaluate to >> a boolean expression), the BLEND has no such constraints and interprets its >> kids as 128-bit vectors. >> >> The patch proposes V16I1V16I1BLEND for pblendvb, but to accommodate all >> other flavors of the blend* operation, the range of rtype/desc will have to >> be extended. In other words, the new operation is intended to represent not >> one, but a set of blend operations. >> >> Thanks. >> Pallavi >> >> -----Original Message----- >> From: Fred Chow [mailto:frdc...@gmail.com] >> Sent: Wednesday, June 15, 2011 2:56 PM >> To: Mathew, Pallavi >> Cc: open64-devel@lists.sourceforge.net >> Subject: Re: [Open64-devel] Code review request for vectorizer patch [LNO] >> [CG] >> >> Instead of defining the new operator BLEND, why don't you just extend >> the existing SELECT operator by allowing it to use V16 types? This is >> what we have been doing when we started to support SIMD types for >> various operations for the x86 target. >> >> Fred >> >> On 06/15/2011 02:18 PM, Mathew, Pallavi wrote: >>> Here is the definition: >>> >>> OPR_BLEND: >>> Ternary operator with rtype=V16I1 and desc=V16I1. >>> Each kid is interpreted as a 128-bit vector of 16 bytes. >>> The result is also a 128-bit vector of bytes computed by >>> selecting bytes from either kid0 or kid1 depending upon >>> value of the mask in kid2 as shown below: >>> if (msb(kid2[n]) == 0) >>> then >>> result[n] = kid0[n] >>> else >>> result[n] = kid1[n] >>> >>> where msb(x) represents the most significant bit of x. >>> and foo[n] represent the n-th byte of foo. >>> >>> -Pallavi >>> >>> >>> -----Original Message----- >>> From: Fred Chow [mailto:frdc...@gmail.com] >>> Sent: Wednesday, June 15, 2011 10:41 AM >>> To: Sun Chan >>> Cc: Mathew, Pallavi; open64-devel@lists.sourceforge.net >>> Subject: Re: [Open64-devel] Code review request for vectorizer patch [LNO] >>> [CG] >>> >>> Instead of look at source code and guessing at the definition of >>> OPR_BLEND, is there some document where we can describe the definition >>> of new WHIRL opcodes? >>> >>> Fred >>> >>> On 06/14/2011 02:51 PM, Sun Chan wrote: >>>> This is a WHIRL change, Fred, can you look at the change (at least the >>>> new OPR_BLEND) to see if that is ok? >>>> Sun >>>> >>>> On Tue, Jun 14, 2011 at 1:39 PM, Mathew, Pallavi<pallavi.mat...@amd.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> Can a gatekeeper please review the attached patch which introduces a >>>>> framework for vectorization of IF-statements of the form: >>>>> >>>>> - if (x != 0) { single_istore_statement } else {empty_body} >>>>> >>>>> - if (x != 0) { if (y !=0) {single_istore_statement} else >>>>> {empty_body}} >>>>> else {empty_body} >>>>> >>>>> >>>>> >>>>> Sample program: >>>>> >>>>> long array[2000000]; >>>>> >>>>> void sample() { >>>>> >>>>> long i; >>>>> >>>>> for(i = 0; i< 2000000; i++) { >>>>> >>>>> if (array[i]) >>>>> >>>>> array[i] ^= i; >>>>> >>>>> } >>>>> >>>>> return; >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> Vectorization of such if-statement is done by first vectorizing its >>>>> subexpressions. >>>>> >>>>> The result of the vectorized if-condition is computed by 'pcmpeqq' >>>>> (V16I8EQ) >>>>> and >>>>> >>>>> is used to select between the result of executing the statement in the >>>>> if-body or >>>>> >>>>> leaving the array element unchanged. This selection is performed by the >>>>> >>>>> 'pblendvb' (V16I1V16I1BLEND) operation. Both of these are SSE4.1 >>>>> instructions. >>>>> >>>>> We introduce a new whirl operation OPR_BLEND which eventually gets >>>>> translated to 'pblendvb'. >>>>> >>>>> This optimization is turned on by default and can be controlled by >>>>> -LNO:simd_vect_if={on/off}. >>>>> >>>>> This patch also recognizes and handles vectorization of invariants rooted >>>>> at >>>>> OPR_ADD, OPR_SUB and OPR_MPY. >>>>> >>>>> >>>>> >>>>> Files updated by this patch: >>>>> >>>>> osprey/be/lno/simd.cxx >>>>> >>>>> - vectorization of if-statements. >>>>> >>>>> - vectorization of invariants rooted at OPR_ADD, OPR_SUB and OPR_MPY. >>>>> >>>>> osprey/common/com/config_lno.h >>>>> >>>>> osprey/common/com/config_lno.cxx >>>>> >>>>> - add flag to control vectorization of if-statements >>>>> >>>>> osprey/common/com/opcode_gen_core.h >>>>> >>>>> - add the OPR_BLEND operation and its opcode. >>>>> >>>>> - add opcode for vectorized version of OPR_EQ. >>>>> >>>>> osprey/common/com/opcode_gen_core.cxx >>>>> >>>>> - specify number of kids, desc, rtype, property(expression), etc. for >>>>> OPR_BLEND. >>>>> >>>>> osprey/common/com/wn.cxx >>>>> >>>>> - enable WN_has_side_effects for opr_blend >>>>> >>>>> osprey/be/opt/opt_bdce.cxx >>>>> >>>>> - propagate live bits down the expression tree. >>>>> >>>>> osprey/be/cg/whirl2ops.cxx >>>>> >>>>> - expand expression containing OPR_BLEND >>>>> >>>>> - add handler for blend. >>>>> >>>>> osprey/be/cg/cgexp_internals.h >>>>> >>>>> - add declaration of Expand_Blend >>>>> >>>>> osprey/be/cg/x8664/expand.cxx >>>>> >>>>> - expand OPC_BLEND to expression containing TNs >>>>> >>>>> osprey/be/com/x8664/betarget.cxx >>>>> >>>>> - convert opcode to TOP... (return top_blend...) >>>>> >>>>> osprey/common/com/wn_util.h >>>>> >>>>> osprey/common/com/wn_util.cxx >>>>> >>>>> - add utility routine. >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Pallavi >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> EditLive Enterprise is the world's most technically advanced content >>>>> authoring tool. Experience the power of Track Changes, Inline Image >>>>> Editing and ensure content is compliant with Accessibility Checking. >>>>> http://p.sf.net/sfu/ephox-dev2dev >>>>> _______________________________________________ >>>>> Open64-devel mailing list >>>>> Open64-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> EditLive Enterprise is the world's most technically advanced content >>>> authoring tool. Experience the power of Track Changes, Inline Image >>>> Editing and ensure content is compliant with Accessibility Checking. >>>> http://p.sf.net/sfu/ephox-dev2dev >>>> _______________________________________________ >>>> Open64-devel mailing list >>>> Open64-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> Open64-devel mailing list >> Open64-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/open64-devel >> >> > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > > -- Regards, Lai Jian-Xin ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
