The only precedent I have seen in recent years for shell scripts is the (absolutely insanely amazingly well-written) utils/TableGen/tdtags. Ignoring the issue of whether this kind of tool belongs in the repo, IMO it would be nice if you used tdtags as a "template" for this script; there's a large amount of shell-fu (not clever "tricks", but actual "how to make a robust, readable, portable shell script"-fu) in there that you will want to imitate.> LLVMHOME=/home/projects/llvm/upstream/llvm-trunk-build/Release+Asserts/bin > SOPTS="-generate-ppc-fp128" > TOPTS="-mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7"Hardcoding these seems a bit "wrong". Are there any reasonable defaults we can use? ((pwd, empty, host triple) for the three options, respectively, might be reasonable?). -- Sean Silva On Wed, Jul 10, 2013 at 7:14 PM, Hal Finkel <hfinkel at anl.gov> wrote:> A few people have requested features; I've implemented them in this > updated version (attached). Do you think this is worth putting in the repo > somewhere? > > -Hal > > ----- Original Message ----- > > Hi, > > > > I wrote a small script in order to stress test llc using test cases > > generated by llvm-stress. When it finds a case where llc seems to > > have crashed, it greps the output for Assertion, LLVM ERROR, etc., > > removes things that look like hex numbers and ID numbers, and then > > checksums the resulting text. In this way, it can automatically > > categorize different bugs into different subdirectories. > > > > I found this useful, and maybe you will too :) > > > > -Hal > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/d9c31d57/attachment.html>
----- Original Message -----> > The only precedent I have seen in recent years for shell scripts is > the (absolutely insanely amazingly well-written) > utils/TableGen/tdtags. > > > Ignoring the issue of whether this kind of tool belongs in the repo,Ah, but do you have an opinion on that?> IMO it would be nice if you used tdtags as a "template" for this > script; there's a large amount of shell-fu (not clever "tricks", but > actual "how to make a robust, readable, portable shell script"-fu) > in there that you will want to imitate.Sounds good. I'll look at it.> > > > > LLVMHOME=/home/projects/llvm/upstream/llvm-trunk-build/Release+Asserts/bin > > SOPTS="-generate-ppc-fp128" > > TOPTS="-mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7" > > > Hardcoding these seems a bit "wrong". Are there any reasonable > defaults we can use? ((pwd, empty, host triple) for the three > options, respectively, might be reasonable?).Sure ;) -- I did not mean to imply that I would commit them that way (although all of these things can be overridden using the command-line arguments). I think that (`pwd`, empty, empty) would make reasonable defaults. Thanks again, Hal> > > -- Sean Silva > > > > > > On Wed, Jul 10, 2013 at 7:14 PM, Hal Finkel < hfinkel at anl.gov > > wrote: > > > A few people have requested features; I've implemented them in this > updated version (attached). Do you think this is worth putting in > the repo somewhere? > > -Hal > > > > ----- Original Message ----- > > Hi, > > > > I wrote a small script in order to stress test llc using test cases > > generated by llvm-stress. When it finds a case where llc seems to > > have crashed, it greps the output for Assertion, LLVM ERROR, etc., > > removes things that look like hex numbers and ID numbers, and then > > checksums the resulting text. In this way, it can automatically > > categorize different bugs into different subdirectories. > > > > I found this useful, and maybe you will too :) > > > > -Hal > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Wed, Jul 10, 2013 at 9:19 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > > > The only precedent I have seen in recent years for shell scripts is > > the (absolutely insanely amazingly well-written) > > utils/TableGen/tdtags. > > > > > > Ignoring the issue of whether this kind of tool belongs in the repo, > > Ah, but do you have an opinion on that? > >For me, the biggest question is whether this will 1. Identify a bunch of bugs, and then they will be fixed, and then the script turns up no more bugs. or 2. Turn up new bugs with regular frequency as options are varied. In case 1, this is really a short-term tool that few people need to actually run and file the bugs it finds. In case 2, we really want this kind of script to make it as easy as possible for as many people as possible to use in as many configurations as possible, and so it makes sense to have it in-tree and available. Which case do you think this falls into? -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130711/caec564a/attachment.html>