Mehdi AMINI via llvm-dev writes:
> The main thing I see that will justify push-back on such test is the
> maintenance: you need to convince everyone that every component in LLVM
> must also maintain (update, fix, etc.) the tests that are in other
> components (clang, flang, other future
David Blaikie via llvm-dev writes:
> & I generally agree that end-to-end testing should be very limited - but
> there are already some end-to-end-ish tests in clang and I don't think
> they're entirely wrong there. I don't know much about the vectorization
> tests - but any test that requires a
> I'm inclined to the direction suggested by others that the monorepo is
> orthogonal to this issue and top level tests might not be the right thing.
>
> lldb already does end-to-end testing in its tests, for instance.
>
> Clang does in some tests (the place I always hit is anything that's
>
"Robinson, Paul via Openmp-dev" writes:
>> I always ran check-all before every patch, FWIW.
>
> Yep. Although I run check-all before *starting* on a patch, to make sure
> the starting point is clean. It usually is, but I've been caught enough
> times to be slightly wary.
This is interesting.
Renato Golin via Openmp-dev writes:
> But if we have some consensus on doing a clean job, then I would
> actually like to have that kind of intermediary check (diagnostics,
> warnings, etc) on most test-suite tests, which would cover at least
> the main vectorisation issues. Later, we could add
Sean Silva via cfe-dev writes:
>> We have to support many different systems and those systems are always
>> changing (new processors, new BIOS, new OS, etc.). Performance can vary
>> widely day to day from factors completely outside the compiler's
>> control. As the performance changes you
Renato Golin via cfe-dev writes:
> On Thu, 10 Oct 2019 at 22:26, David Greene wrote:
>> That would be a shame. Where is test-suite run right now? Are there
>> bots? How are regressions reported?
>
> There is no shame in making the test-suite better.
That's not what I meant, sorry. I mean
"Robinson, Paul via Openmp-dev" writes:
> David Greene, will you be at the LLVM Dev Meeting? If so, could you sign
> up for a Round Table session on this topic? Obviously lots to discuss
> and concerns to be addressed.
That's a great idea. I will be there. I'm also hoping to help run a
Renato Golin via cfe-dev writes:
> I'd recommend trying to move any e2e tests into the test-suite and
> make it easier to run, and leave specific tests only in the repo (to
> guarantee independence of components).
That would be a shame. Where is test-suite run right now? Are there
bots? How
Florian Hahn via cfe-dev writes:
> Have you considered alternatives to checking the assembly for ensuring
> vectorization or other transformations? For example, instead of
> checking the assembly, we could check LLVM’s statistics or
> optimization remarks.
Yes, absolutely. We have tests that
Florian Hahn via llvm-dev writes:
>> - Performance varies from implementation to implementation. It is
>> difficult to keep tests up-to-date for all possible targets and
>> subtargets.
>
> Could you expand a bit more what you mean here? Are you concerned
> about having to run the performance
Philip Reames via cfe-dev writes:
> A challenge we already have - as in, I've broken these tests and had to
> fix them - is that an end to end test which checks either IR or assembly
> ends up being extraordinarily fragile. Completely unrelated profitable
> transforms create small
Mehdi AMINI via cfe-dev writes:
> I don't think these particular tests are the most controversial though, and
> it is really still fairly "focused" testing. I'm much more curious about
> larger end-to-end scope: for instance since you mention debug info and
> LLDB, what about a test that would
Mehdi AMINI via llvm-dev writes:
>> I absolutely disagree about vectorization tests. We have seen
>> vectorization loss in clang even though related LLVM lit tests pass,
>> because something else in the clang pipeline changed that caused the
>> vectorizer to not do its job.
>
> Of course, and
Mehdi AMINI via cfe-dev writes:
>> I have a bit of concern about this sort of thing - worrying it'll lead to
>> people being less cautious about writing the more isolated tests.
>>
>
> I have the same concern. I really believe we need to be careful about
> testing at the right granularity to
David Blaikie via Openmp-dev writes:
> I have a bit of concern about this sort of thing - worrying it'll lead to
> people being less cautious about writing the more isolated tests.
That's a fair concern. Reviewers will still need to insist on small
component-level tests to go along with
[ I am initially copying only a few lists since they seem like
the most impacted projects and I didn't want to spam all the mailing
lists. Please let me know if other lists should be included. ]
I submitted D68230 for review but this is not about that patch per se.
The patch allows
Tom Stellard via llvm-dev writes:
> 1. Have either a status check or use the "Rebase and Merge" policy for
> pull requests to disallow merge commits. Disable direct pushes to the
> master branch and update the git-llvm script to create a pull request
> when a developer does `git llvm push` and
Oh, I'm completely in favor of making bad commits much less likely. I
simply think there is a decent solution between "let everything in" and
"don't let everything in unless its proven to work everywhere" that gets
90% of the improvement. The complexity of guaranteeing a buildable
branch is
Roman Lebedev writes:
> *Does* LLVM want to switch from phabricator to github pr's?
> I personally don't recall previous discussions.
> Personally, i hope not, i hope phabricator should/will stay.
I find Phab pretty unintuitive. I just started using it in earnest
about four months ago, so
Björn Pettersson A writes:
>> Ok, in that case I would expect the resulting history to look like
>> this:
>>
>> UL4->UC2->UL3->UL2->UL1->UL0->UC1 <- monorepo/master
>> | \
>> \ `---.
>>
writes:
> Systems that I've seen will funnel all submitted PRs into a single queue
> which *does* guarantee that the trial builds are against HEAD and there
> are no "later commits" that can screw it up. If the trial build passes,
> the PR goes in and becomes the new HEAD.
The downside of a
Mehdi AMINI writes:
> What is the practical plan to enforce the lack of merges? When we
> looked into this GitHub would not support this unless also forcing
> every change to go through a pull request (i.e. no pre-receive hooks
> on direct push to master were possible). Did this change? Are we
>
Björn Pettersson A writes:
> In llvm (split) we have:
>
> UL4->UL3->UL2->UL1->UL0
>\
> ...->DL2->DL1
>
> In clang (split) we have:
>
> UC4->UC3->UC2->UC1->UC0
>\
> ...->DC2->DC1
>
>
> DL1 is a commit that updates the clang submodule
Jeremy Lakeman via llvm-dev writes:
> 4. Each reviewed bug / feature must be rebased onto the current "known
> good" commit, merged into a "probably good" commit, tested by build
> bots, and only then pushed to trunk. Keeping trunk's history more
> usable, with most bad patches reworked and
Bruce Hoult via llvm-dev writes:
> How about:
>
> Require a rebase, followed by git merge --no-ff
>
> This creates a linear history, but with extra null merge commits
> delimiting each related series of patches.
>
> I believe it is compatible with bisect.
>
>
Tom Stellard via Openmp-dev writes:
> As part of the migration of LLVM's source code to github, we need to update
> our developer policy with instructions about how to interact with the new git
> repository. There are a lot of different topics we will need to discuss, but
> I would like to
Björn Pettersson A writes:
> In the new monorepo UC1 may or may not be a parent to UL1.
> We could actually have something like this:
>
> UL4->UC2->UL3->UL2->UL1->UL0->UC1
>
> Our DL1 commit should preferably have UL1 as parent after
> conversion
>
> UL4->UC2->UL3->UL2->UL1->UL0->UC1
>
He all,
I've updated the downstream fork zipping tool that I posted about last
November [1]. It is much improved in every way. The most important
enhancements are:
- Does a better job of simplifying history
- Handles nested submodules
- Will put non-submodule-update content in a subdirectory
I've created a tool that takes a downstream repository and imports it
into the monorepo such that trees appear under a given subdirectory in
the monorepo:
https://github.com/jyknight/llvm-git-migration/pull/6
This is useful for downstream users who have repositories that make
heavy use of LLVM
David Greene via llvm-dev writes:
> Now that I think about it, what you really want is something that runs
> migrate-downstream-fork.py on the commits in llvm and something that
> runs zip-downstream-fork.py on commits in other projects, but they have
> to ruin simultaneously to keep the commits
Björn Pettersson A writes:
> We have used llvm as the umbrella repo, so in llvm we have a "master"
> branch (from the git single repo version of llvm) and a couple of
> downstream branches (let's call them "down0", "down1") containing our
> downstream work (with frequent merges from "master").
Building on the great work that James Knight did on
migrate-downstream-fork.py (Thanks, James!) [1], I've created a simple
tool to take migrated downstream fork branches and zip them into a
single history given a history containing submodule updates of
subprojects [2].
With
Zachary Turner via llvm-dev writes:
> Just so I'm clear, are we going to attempt to clean up and/or merge
> the components? If we are, it makes sense to do that before we start
> putting ourselves as default CC's on the various components since they
> will just change. If not, it would be nice
Richard Smith via cfe-dev writes:
> In fact, I think it'd be entirely reasonable to subscribe cfe-dev to
> all clang bugs (fully subscribe -- email on all updates!). I don't see
> any reason whatsoever why a bug update should get *less* attention
> than non-bug development discussion.
Some of
Apparently the GitHub UI is not great about showing tags. If you clone
and do git tag you'll see them. Someone at one of the dev. meeting
roundtables found a way to see them on GitHub but I don't remember the
details.
-David
Jacob Carlborg via llvm-dev writes:
> On
Thanks! In our case we have a branch off master for each component and
we've developed there, merging from master from time to time (but never
our local branch to master). I guess that puts us in the "multirepo
with merges" category. We don't really care about maintaining the
history of merges
I had a short side-conversation at one of the roundtables about existing
users of the subproject repositories. It would be helpful to have
instructions about the best way to move local branches in those
repositories to the monorepo and some scripts to help with the
transition. I know someone
38 matches
Mail list logo
