[cfe-dev] fp-contract at -O0
Blower, Melanie I via cfe-dev
cfe-dev at lists.llvm.org
Thu Mar 5 10:58:29 PST 2020
Hello everyone,
A few weeks ago I submitted, then reverted, a patch to default the behavior of ffp-contract to "on". There was discussion on cfe-dev and while the opinions weren't unanimous, there was large support for this choice. This is associated with the default for the option -ffp-model=precise, which should choose -ffp-contract=on.
After the patch was submitted, the LNT build bots reported performance regressions in about 20 tests on a couple different architecture including x86 and aarch64. It seemed to be about the same 20 tests failing across the different architecture. Later the patch was reverted due to the performance regressions. Andy Kaylor told me he thought the regressions were due to the Loop Unroller making non-optimal decisions when -ffp-contract=on.
A couple questions about this:
I'd like to learn how to dig into the LNT performance regressions, any tips or guidance about this?
I'd like to learn how to get the information from the LNT build bot.
1. Do I need to sit there watching the url, else the history will scroll past and be removed?
2. Is there a way to run the LNT tests from my bash shell?
3. There are SHA codes in the LNT url, but they don't seem to correspond to the SHA when I say "git log"
4. If 20 LNT tests have performance regressions but 5000 LNT tests are the same or better, is there a process to approve the change and incur performance regression, possibly opening a bug report to improve the 20 tests that regressed?
Thanks for any insight. --Melanie
> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of via cfe-dev
> Sent: Thursday, February 20, 2020 6:57 AM
> To: cfe-dev at lists.llvm.org
> Subject: cfe-dev Digest, Vol 152, Issue 46
>
> Send cfe-dev mailing list submissions to
> cfe-dev at lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> or, via email, send a message with subject or body 'help' to
> cfe-dev-request at lists.llvm.org
>
> You can reach the person managing the list at
> cfe-dev-owner at lists.llvm.org
>
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of cfe-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: fp-contract at -O0 (Arthur O'Dwyer via cfe-dev)
> 2. AST Serialization (Endre Fülöp via cfe-dev)
> 3. Re: [llvm-dev] MLIR for clang (Prashanth N R via cfe-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 19 Feb 2020 22:44:39 -0500
> From: Arthur O'Dwyer via cfe-dev <cfe-dev at lists.llvm.org>
> To: David Greene <greened at obbligato.org>, "cfe-dev at lists.llvm.org"
> <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] fp-contract at -O0
> Message-ID:
> <CADvuK0+bw5iLpwTPJa4QrgS51RLsEqSiOEVNmY9QgRbb5HTQJg at m
> ail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Feb 19, 2020 at 12:22 PM David Greene via cfe-dev < cfe-
> dev at lists.llvm.org> wrote:
>
> > Stephen Canon <scanon at apple.com> writes:
> > >> On Feb 18, 2020, at 2:01 PM, David Greene <greened at obbligato.org>
> > wrote:
> > >>
> > >> There are many cases where FMA is not desired and most users don't
> > >> expect fused operations at -O0 unless they specifically ask for it.
> > >
> > > If FMA is not desired, -ffp-contract=off or the pragma should be
> > > used to disable it. -O0 is the wrong tool for that job.
> >
> > Why? Many of our customers would be surprised to see FMAs at -O0.
> >
>
> Jumping in with my opinion, as this thread doesn't seem to be dying of its own
> accord:
>
> The -O0 level is supposed to be the compiler's "default" optimization level —
> that is, the "simplest possible" optimization level, the fastest one, the one that
> just flows through the compiler without taking any unnecessary detours or side
> quests. -O0 is the level where you get *the thing that just works*, without
> applying any additional post-processing to it.
>
> In fact, film "post-processing" is a good way to think about optimization.
> -O0 codegen is like the dailies <https://en.wikipedia.org/wiki/Dailies>
> straight from the camera. Optimization options, -ffp-contract=whatever, and so
> on, are all inputs (from the human "director-producer") to the guy who does
> the post-processing, saying "take this raw footage, as it came from the camera,
> and— look for some extra FMAs, or lower the ones that basic codegen already
> put there, or whatever."
>
> The innards of the compiler always look basically like this:
>
> do_some_codegen();
> if (some_option) {
> postprocess_the_codegen_to_satisfy_a_whim_of_the_director();
> }
>
> The "-O0" path is *by definition* the path that does not take that `if` branch. I
> don't care if the whim is "I want more FMAs" or "I want fewer FMAs" or "I want
> more spills to stack" or "I want fewer spills to stack" or whatever. The "-O0"
> path is *by definition* the path that does not cater to any whim except "I want
> to see the dailies as soon as possible."
>
> Which is to say, Stephen Canon and Joerg Sonnenberger are correct.
>
> –Arthur
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/cfe-
> dev/attachments/20200219/c4a1c376/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Feb 2020 09:35:21 +0000
> From: Endre Fülöp via cfe-dev <cfe-dev at lists.llvm.org>
> To: "cfe-dev at lists.llvm.org" <cfe-dev at lists.llvm.org>
> Subject: [cfe-dev] AST Serialization
> Message-ID: <98f71783fe164f8b9a68cdf348354a03 at sigmatechnology.se>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I have a question regarding the assumptions and correct usage of the AST
> serialization (regarding C and C++ sources).
>
> I have done the following:
>
> 1) I have implemented a ClangTool which builds ASTs from compilation
> databases.
>
> 2) I have dumped the contents of the ASTs in both textual and binary formats.
>
> 3) Then I have read in the serialized binary, and dumped that one again in
> both formats.
>
> What I have noticed, is that dump of the different generations are different in
> size (up to a magnitude). Textual dumps also differ.
> I would have assumed the serialization and deserialization steps to produce an
> AST which is the same as the original.
>
> Maybe I have done it the wrong way, in the following outline I try to give the gist
> of the method used:
>
> void textual_dump_to_file(const ASTUnit& unit, StringRef file_path) {
> using namespace llvm::sys::fs;
> using namespace llvm::sys::path;
>
> // mkdir -p
> create_directories(parent_path(file_path));
>
> std::error_code EC;
> llvm::raw_fd_ostream out {file_path, EC};
> unit.getASTContext().getTranslationUnitDecl()->dump(out, /*deserialize*/
> true); }
>
> void experiment_with_unit(CompilerInstance& CI, ASTUnit& Unit, StringRef
> MethodPrefix, StringRef SourcePath) {
>
> using namespace llvm::sys::fs;
> using namespace llvm::sys::path;
>
> IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions();
> TextDiagnosticPrinter *DiagClient = new TextDiagnosticPrinter(llvm::errs(),
> &*DiagOpts);
> IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
> IntrusiveRefCntPtr<DiagnosticsEngine> Diags(
> new DiagnosticsEngine(DiagID, &*DiagOpts, DiagClient));
>
> llvm::SmallString<256> TextDumpPath{MethodPrefix};
> TextDumpPath.append(SourcePath);
>
> llvm::SmallString<256> BinaryDumpPath {TextDumpPath};
>
> replace_extension(TextDumpPath, ".txt1");
> replace_extension(BinaryDumpPath, ".bin1");
>
> Unit.Save(BinaryDumpPath);
>
> textual_dump_to_file(Unit, TextDumpPath);
>
> auto Dump1Loaded = ASTUnit::LoadFromASTFile(
> std::string(BinaryDumpPath), CI.getPCHContainerOperations()-
> >getRawReader(),
> ASTUnit::LoadEverything, Diags, CI.getFileSystemOpts());
>
> replace_extension(TextDumpPath, ".txt2");
> replace_extension(BinaryDumpPath, ".bin2");
>
> Dump1Loaded->Save(BinaryDumpPath);
> textual_dump_to_file(*Dump1Loaded, TextDumpPath); }
>
> Files with extensions txt1 and txt2 differ, and bin1 and bin2 as well.
> I would think that if there is a problem in the reproducibility of the AST, then it
> would affect modules, and the analyzer as well.
>
> Any thoughts on this?
>
> Thanks
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/cfe-
> dev/attachments/20200220/e113133f/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 20 Feb 2020 17:24:36 +0530
> From: Prashanth N R via cfe-dev <cfe-dev at lists.llvm.org>
> To: David Chisnall <David.Chisnall at cl.cam.ac.uk>
> Cc: cfe-dev <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] [llvm-dev] MLIR for clang
> Message-ID:
> <CAEMPOObbFkBNq2L4VEOKdXZw4408AW8zsyRD7zV8pwkKSKcavA
> @mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks David for good design pointers. We are thinking about the design issues
> and we will look into it soon.
>
> -Prashanth
>
> On Tue, Feb 18, 2020 at 4:36 PM David Chisnall via cfe-dev < cfe-
> dev at lists.llvm.org> wrote:
>
> > [ Dropping llvm-dev, because this seems to be entirely a discussion
> > about clang ]
> >
> > On 16/02/2020 11:03, Nicolai Hähnle via cfe-dev wrote:
> > > On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev
> > > <llvm-dev at lists.llvm.org> wrote:
> > >>> Starting from May-June, we at "Compiler Tree" would start
> > >>> porting
> > clang compiler to use MLIR as middle end target. If someone has
> > already started a similar effort we would love to collaborate with
> > them. If someone would like to work with us, we are ready to form a group
> and collaborate.
> > If there are sharing opportunities from Fortran side, we would like to
> > consider the same.\
> > > That's a rather vague statement, considering the flexibility of MLIR.
> > > Could you explain your plans in more detail, and what specifically
> > > you hope to achieve with them?
> >
> > I agree. There are several possible goals here and the approach that
> > makes sense will vary. For example, if you just want to unify OpenMP
> > support between clang and f18. This could be accomplished by
> > mechanically translating the LLVM builder calls to builder calls for
> > the LLVM IR embedding in MLIR and adding the other OpenMP-specific parts.
> > There are a few more complex things that I can imagine being of value:
> >
> > 1. Embedding enough [Objective-]C[++] high-level semantic information
> > in a new MLIR dialect that the static analyser can operate on this
> > representation and it can then be lowered to LLVM IR.
> >
> > 2. Embedding the full C (or even C++) type system in MLIR such that
> > other front ends can target a C ABI and reuse clang's MLIR -> LLVM IR
> > lowering pass to incorporate ABI-specific details.
> >
> > 3. Deferring C++ and Objective-C dynamic dispatch lowering until later
> > to retain more source-level type information for devirtualization or
> > more precise CFI implementations.
> >
> > These are the first things that pop into my head and each one imposes
> > a different set of requirements on the MLIR dialect that you'll be
> > lowering to (though it's also possible to imagine a superset that
> > supports all of these use cases).
> >
> > David
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/cfe-
> dev/attachments/20200220/da026475/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> ------------------------------
>
> End of cfe-dev Digest, Vol 152, Issue 46
> ****************************************
More information about the cfe-dev
mailing list