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
> ****************************************