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
