1.p has no assertion. Can you add? E.g. I would assert num_bbs no less than 1. The func LOOP_Block_Merge is not targ_x86, is it? As long as the call to it is TARG_X8664, it should be fine. 2.p, you are using bool, please use BOOL like that of 1.p if the segment: bool uses_destructive_dest = FALSE; if( BB_regpressure(bb,TN_register_class(result)) && (TN_register_class(result) == ISA_REGISTER_CLASS_float) ){ INT num_pr = REGISTER_CLASS_register_count(ISA_REGISTER_CLASS_float); INT num_measured = BB_regpressure(bb,ISA_REGISTER_CLASS_float); if (num_measured > (AVX_FP_REG_FACTOR * num_pr)) uses_destructive_dest = TRUE;
is a function (or template), your function interface should be much cleaner that it is now, and is easier to maintain in the future. Also, I would set Is_TN_Sdsu to return false for non TARG_X86 3.p looks fine 4.p looks fine 5.p looks fine 6.p looks fine Sun On Sat, Jul 9, 2011 at 6:43 AM, Berg, Michael <michael.b...@amd.com> wrote: > It’s been a while, can a gatekeeper pls have a look at this patch. > > > > Thx, > > > > m > > > > From: Berg, Michael > Sent: Friday, July 01, 2011 12:14 PM > To: 'open64-devel@lists.sourceforge.net' > Subject: Gatekeeper code review request for AMD 4.2.5.1 merge > > > > All: The attached patch files are: > > > > 1.) Remainder loop coalescing code to single block for cg > > 2.) Register pressure table updates and lra utility additions for > register pressure detection > > 3.) Addition of movddup to cg expansion for BD and jump table offset > corrections for BD > > 4.) FMA disassociation addition for register pressure > > 5.) Translation table updates, scheduling updates and assembler emit > corrections to formatting for BD > > 6.) Target updates for vmovdqu and cg memin/memout size constraint > corrections for BD > > > > Can a Gatekeeper please review these changes which are part of our ongoing > effort for BD support and code quality. > > > > These changes pass the following: > > a.) No compile time failure for x86 build. > > b.) The gcc regression test suite on x86/Linux with no new > failures. > > c.) The SPEC2006 test suite at with current AMD 1 copy config at > both base and peak. > > > > Thx, > > > > m > > > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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