[llvm-dev] [cfe-dev] [test-suite] making the test-suite succeed with "-Ofast" and "-ffp-contract=on"

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Sat Oct 8 14:36:02 PDT 2016


----- Original Message -----
> From: "Sebastian Pop via cfe-dev" <cfe-dev at lists.llvm.org>
> To: "Renato Golin" <renato.golin at linaro.org>
> Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias Braun"
> <matze at braunis.de>, "Clang Dev" <cfe-dev at lists.llvm.org>, "nd" <nd at arm.com>, "Abe Skolnik" <a.skolnik at samsung.com>
> Sent: Saturday, October 8, 2016 8:25:49 AM
> Subject: Re: [cfe-dev] [llvm-dev] [test-suite] making the test-suite succeed with "-Ofast" and "-ffp-contract=on"
> 
> On Sat, Oct 8, 2016 at 6:17 AM, Renato Golin via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > Proposal 4:
> >
> > Investigate each problematic benchmark and apply the best solution
> > for
> > each one of them, independently. For oggenc we may need something
> > different.
> >
> [...]
> > My proposal is to go through all 50 cases and propose the lowest
> > number of solutions possible for all of them. I'm guessing this
> > will
> > be between 2 and 4 different cases.
> >
> 
> I like Proposal 4: we need different patches to different problems.
> I am sure we do not have an understanding of all the problems in the
> 50
> currently failing benchmarks, so we will need to analyze each
> problem.
> 
> > The proposal 2 is actually good for Polybench, at least for the one
> > case where Sebastian has implemented. Yes, it doubles run time, but
> > it's validation run time, which is part of the test, and it doesn't
> > bloat disk/memory.
> 
> I see that handling Polybench separately as in Proposal 2 also falls
> under Proposal 4, as handling that benchmark separately from the
> other
> ones that may have different problems.
> 
> A separate follow-up patch can link a hashing algorithm in each
> test of Polybench and output the hashed result to reduce I/O.
> 
> If everybody agrees on starting by fixing Polybench as described in
> Proposal 2, I will complete the implementation of that patch, and
> follow-up
> with the hashing of the output.

Yes, please fix polybench. I'm still not sure how much we should generalize this solution to other benchmarks, but polybench needs fixing somehow anyway, and this will be a big help.

 -Hal

> 
> Thanks,
> Sebastian
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-dev mailing list