Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Diana Picus via lldb-dev]

Hi,

Is this monotonic incrementing identifier part of the email? I think
it would really complicate buildbot maintenance if we didn't have it
in obvious places. For instance, we have a (hacky) monitoring page for
our ARM/AArch64 buildbots [1] and it really helps a lot to just look
at the commit range for the last build to know if a fix actually
worked or not ("is the fix commit in that range? if not wait a bit
more before investigating"). Using just a git hash and having to
manually count commits would be a waste of time.

Just my 2c,
Diana

[1] http://llvm.validation.linaro.org/

On Wed, 16 Oct 2019 at 07:42, Shoaib Meenai via llvm-dev
 wrote:
>
> I thought we were just going to count commits on a particular branch and use 
> the (branch name, commit count) tuple as our monotonic incrementing 
> identifier? 
> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
>
>
>
>
>
> From: cfe-dev  on behalf of cfe-dev 
> 
> Organization: Red Hat
> Reply-To: "tstel...@redhat.com" 
> Date: Tuesday, October 15, 2019 at 10:13 PM
> To: Mehdi AMINI 
> Cc: llvm-dev , cfe-dev , 
> "openmp-dev (openmp-...@lists.llvm.org)" , LLDB 
> Dev 
> Subject: Re: [cfe-dev] Mailing list changes this week
>
>
>
> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
>
> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard  > wrote:
>
>  On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
>
>  > Hi Tom.
>
>  >
>
>  > One issue with this is that we don't have a clear "ordering" from 
> linear revision numbers from these emails. Have we looked into continuing to 
> generate our own emails per commits instead so that we control the format?
>
>  >
>
>  This actually what we are doing, we are listening for github commit 
> events and
>
>  then generating our own emails based on the data in the event.  We can 
> format
>
>  the emails how ever we want, and we tried to match the current SVN 
> format exactly.
>
> Ah great!
>
>
>
>  Is the some other information you would like to have in the emails to 
> show the
>
>  ordering?
>
> The only thing I was looking to get was to continue to have a monotonic 
> incrementing integer for the revision instead of the git hash alone: I don't 
> know if `git llvm` has this feature yet but this was discussed a while ago (I 
> don't remember if we just mentioned counting the commits in the repo from the 
> beginning or using an invocation of `git describe` or something derived).
>
>
>
> We talked about using `git describe` for this, but this would require that we
>
> add tags to the master branch each time the version number was bumped.  We
>
> discussed this[1] last year, but deferred the decision, since we couldn't get
>
> consensus on the tag name.
>
>
>
> -Tom
>
>
>
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=
>
>
>
> --
>
> Mehdi
>
>
>
>  -Tom
>
>  > Thanks,
>
>  >
>
>  > --
>
>  > Mehdi
>
>  >
>
>  >
>
>  >
>
>  > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
>
>  >
>
>  > Hi,
>
>  >
>
>  > We are going to start to switching from SVN commit emails to 
> GitHub commit
>
>  > emails this week.  The only real change you should notice is that
>
>  > the revision number in the subject will be replaced with a git 
> hash and
>
>  > the diff links in the email will point to GitHub.  Otherwise the
>
>  > content and format of the email should be the same.
>
>  >
>
>  > We are going to start by rolling this out for the openmp-commits 
> list
>
>  > and then once that's working begin migrating the rest of the 
> lists.  If you
>
>  > notice any issues with the new emails, please file a bug and mark 
> it
>
>  > as a blocker of the github meta-bug (llvm.org/PR39393 
>   > 
>   >).
>
>  >
>
>  > Thanks,
>
>  > Tom
>
>  > ___
>
>  > cfe-dev mailing list
>
>  > cfe-...@lists.llvm.org  
> >
>
>  > 
> https://urldefense.proofpoint.com/v2/url?u=htt

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Robinson, Paul via lldb-dev]

+1.  And put it in the email (subject?).  While it’s possible to derive a count 
from a hash manually, better to have it in the email in the first place.  You 
can’t rely on order-of-email-delivery to reflect order-of-commit.
--paulr

From: llvm-dev  On Behalf Of Shoaib Meenai via 
llvm-dev
Sent: Wednesday, October 16, 2019 1:42 AM
To: tstel...@redhat.com; Mehdi AMINI 
Cc: llvm-dev ; cfe-dev ; 
openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 

Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week

I thought we were just going to count commits on a particular branch and use 
the (branch name, commit count) tuple as our monotonic incrementing identifier? 
https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git


From: cfe-dev 
mailto:cfe-dev-boun...@lists.llvm.org>> on 
behalf of cfe-dev mailto:cfe-...@lists.llvm.org>>
Organization: Red Hat
Reply-To: "tstel...@redhat.com" 
mailto:tstel...@redhat.com>>
Date: Tuesday, October 15, 2019 at 10:13 PM
To: Mehdi AMINI mailto:joker@gmail.com>>
Cc: llvm-dev mailto:llvm-...@lists.llvm.org>>, cfe-dev 
mailto:cfe-...@lists.llvm.org>>, "openmp-dev 
(openmp-...@lists.llvm.org)" 
mailto:openmp-...@lists.llvm.org>>, LLDB Dev 
mailto:lldb-dev@lists.llvm.org>>
Subject: Re: [cfe-dev] Mailing list changes this week

On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard 
mailto:tstel...@redhat.com> 
> wrote:
 On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
 > Hi Tom.
 >
 > One issue with this is that we don't have a clear "ordering" from linear 
revision numbers from these emails. Have we looked into continuing to generate 
our own emails per commits instead so that we control the format?
 >
 This actually what we are doing, we are listening for github commit events 
and
 then generating our own emails based on the data in the event.  We can 
format
 the emails how ever we want, and we tried to match the current SVN format 
exactly.
Ah great!

 Is the some other information you would like to have in the emails to show 
the
 ordering?
The only thing I was looking to get was to continue to have a monotonic 
incrementing integer for the revision instead of the git hash alone: I don't 
know if `git llvm` has this feature yet but this was discussed a while ago (I 
don't remember if we just mentioned counting the commits in the repo from the 
beginning or using an invocation of `git describe` or something derived).

We talked about using `git describe` for this, but this would require that we
add tags to the master branch each time the version number was bumped.  We
discussed this[1] last year, but deferred the decision, since we couldn't get
consensus on the tag name.

-Tom

[1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=

--
Mehdi

 -Tom
 > Thanks,
 >
 > --
 > Mehdi
 >
 >
 >
 > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
mailto:cfe-...@lists.llvm.org> 
 >> wrote:
 >
 > Hi,
 >
 > We are going to start to switching from SVN commit emails to GitHub 
commit
 > emails this week.  The only real change you should notice is that
 > the revision number in the subject will be replaced with a git hash 
and
 > the diff links in the email will point to GitHub.  Otherwise the
 > content and format of the email should be the same.
 >
 > We are going to start by rolling this out for the openmp-commits list
 > and then once that's working begin migrating the rest of the lists.  
If you
 > notice any issues with the new emails, please file a bug and mark it
 > as a blocker of the github meta-bug (llvm.org/PR39393 
 
).
 >
 > Thanks,
 > Tom
 > ___
 > cfe-dev mailing list
 > cfe-...@lists.llvm.org 
 

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 07:31 AM, Roman Lebedev wrote:
> +1, please.
> 
> Also, putting a tag on the *first* commit in the repo,
> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*!
> 

Do we need to add a tag or is `git rev-list --count HEAD`
good enough?

-Tom


> Roman.
> 
> On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev
>  wrote:
>>
>> +1.  And put it in the email (subject?).  While it’s possible to derive a 
>> count from a hash manually, better to have it in the email in the first 
>> place.  You can’t rely on order-of-email-delivery to reflect order-of-commit.
>>
>> --paulr
>>
>>
>>
>> From: llvm-dev  On Behalf Of Shoaib Meenai 
>> via llvm-dev
>> Sent: Wednesday, October 16, 2019 1:42 AM
>> To: tstel...@redhat.com; Mehdi AMINI 
>> Cc: llvm-dev ; cfe-dev ; 
>> openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 
>> 
>> Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week
>>
>>
>>
>> I thought we were just going to count commits on a particular branch and use 
>> the (branch name, commit count) tuple as our monotonic incrementing 
>> identifier? 
>> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
>>
>>
>>
>>
>>
>> From: cfe-dev  on behalf of cfe-dev 
>> 
>> Organization: Red Hat
>> Reply-To: "tstel...@redhat.com" 
>> Date: Tuesday, October 15, 2019 at 10:13 PM
>> To: Mehdi AMINI 
>> Cc: llvm-dev , cfe-dev , 
>> "openmp-dev (openmp-...@lists.llvm.org)" , LLDB 
>> Dev 
>> Subject: Re: [cfe-dev] Mailing list changes this week
>>
>>
>>
>> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
>>
>> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard > > wrote:
>>
>>  On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
>>
>>  > Hi Tom.
>>
>>  >
>>
>>  > One issue with this is that we don't have a clear "ordering" from 
>> linear revision numbers from these emails. Have we looked into continuing to 
>> generate our own emails per commits instead so that we control the format?
>>
>>  >
>>
>>  This actually what we are doing, we are listening for github commit 
>> events and
>>
>>  then generating our own emails based on the data in the event.  We can 
>> format
>>
>>  the emails how ever we want, and we tried to match the current SVN 
>> format exactly.
>>
>> Ah great!
>>
>>
>>
>>  Is the some other information you would like to have in the emails to 
>> show the
>>
>>  ordering?
>>
>> The only thing I was looking to get was to continue to have a monotonic 
>> incrementing integer for the revision instead of the git hash alone: I don't 
>> know if `git llvm` has this feature yet but this was discussed a while ago 
>> (I don't remember if we just mentioned counting the commits in the repo from 
>> the beginning or using an invocation of `git describe` or something derived).
>>
>>
>>
>> We talked about using `git describe` for this, but this would require that we
>>
>> add tags to the master branch each time the version number was bumped.  We
>>
>> discussed this[1] last year, but deferred the decision, since we couldn't get
>>
>> consensus on the tag name.
>>
>>
>>
>> -Tom
>>
>>
>>
>> [1] 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=
>>
>>
>>
>> --
>>
>> Mehdi
>>
>>
>>
>>  -Tom
>>
>>  > Thanks,
>>
>>  >
>>
>>  > --
>>
>>  > Mehdi
>>
>>  >
>>
>>  >
>>
>>  >
>>
>>  > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
>> mailto:cfe-...@lists.llvm.org> 
>> >> wrote:
>>
>>  >
>>
>>  > Hi,
>>
>>  >
>>
>>  > We are going to start to switching from SVN commit emails to 
>> GitHub commit
>>
>>  > emails this week.  The only real change you should notice is that
>>
>>  > the revision number in the subject will be replaced with a git 
>> hash and
>>
>>  > the diff links in the email will point to GitHub.  Otherwise the
>>
>>  > content and format of the email should be the same.
>>
>>  >
>>
>>  > We are going to start by rolling this out for the openmp-commits 
>> list
>>
>>  > and then once that's working begin migrating the rest of the 
>> lists.  If you
>>
>>  > notice any issues with the new emails, please file a bug and mark 
>> it
>>
>>  > as a blocker of the github meta-bug (llvm.org/PR39393 
>> >  > 
>> 

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 12:02 PM, Roman Lebedev wrote:
> On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard  wrote:
>>
>> On 10/16/2019 07:31 AM, Roman Lebedev wrote:
>>> +1, please.
>>>
>>> Also, putting a tag on the *first* commit in the repo,
>>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*!
>>>
>>
>> Do we need to add a tag or is `git rev-list --count HEAD`
>> good enough?
> Ah, interesting, that works too, better than nothing.
> But to be noted that number is different from the `llvm-svn: <>` for
> the current commit.
> 

This is expected.  There were a few commits that were filtered
out in the SVN to git conversion:

https://github.com/jyknight/llvm-git-migration/blob/master/llvm-svn2git-monorepo.rules

-Tom

>> -Tom
> Roman
> 
>>> Roman.
>>>
>>> On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev
>>>  wrote:

 +1.  And put it in the email (subject?).  While it’s possible to derive a 
 count from a hash manually, better to have it in the email in the first 
 place.  You can’t rely on order-of-email-delivery to reflect 
 order-of-commit.

 --paulr



 From: llvm-dev  On Behalf Of Shoaib 
 Meenai via llvm-dev
 Sent: Wednesday, October 16, 2019 1:42 AM
 To: tstel...@redhat.com; Mehdi AMINI 
 Cc: llvm-dev ; cfe-dev ; 
 openmp-dev (openmp-...@lists.llvm.org) ; LLDB 
 Dev 
 Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week



 I thought we were just going to count commits on a particular branch and 
 use the (branch name, commit count) tuple as our monotonic incrementing 
 identifier? 
 https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git





 From: cfe-dev  on behalf of cfe-dev 
 
 Organization: Red Hat
 Reply-To: "tstel...@redhat.com" 
 Date: Tuesday, October 15, 2019 at 10:13 PM
 To: Mehdi AMINI 
 Cc: llvm-dev , cfe-dev , 
 "openmp-dev (openmp-...@lists.llvm.org)" , LLDB 
 Dev 
 Subject: Re: [cfe-dev] Mailing list changes this week



 On 10/15/2019 09:44 PM, Mehdi AMINI wrote:

 On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard >>> > wrote:

  On 10/15/2019 09:24 PM, Mehdi AMINI wrote:

  > Hi Tom.

  >

  > One issue with this is that we don't have a clear "ordering" from 
 linear revision numbers from these emails. Have we looked into continuing 
 to generate our own emails per commits instead so that we control the 
 format?

  >

  This actually what we are doing, we are listening for github commit 
 events and

  then generating our own emails based on the data in the event.  We 
 can format

  the emails how ever we want, and we tried to match the current SVN 
 format exactly.

 Ah great!



  Is the some other information you would like to have in the emails to 
 show the

  ordering?

 The only thing I was looking to get was to continue to have a monotonic 
 incrementing integer for the revision instead of the git hash alone: I 
 don't know if `git llvm` has this feature yet but this was discussed a 
 while ago (I don't remember if we just mentioned counting the commits in 
 the repo from the beginning or using an invocation of `git describe` or 
 something derived).



 We talked about using `git describe` for this, but this would require that 
 we

 add tags to the master branch each time the version number was bumped.  We

 discussed this[1] last year, but deferred the decision, since we couldn't 
 get

 consensus on the tag name.



 -Tom



 [1] 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=



 --

 Mehdi



  -Tom

  > Thanks,

  >

  > --

  > Mehdi

  >

  >

  >

  > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
 mailto:cfe-...@lists.llvm.org> 
 >> wrote:

  >

  > Hi,

  >

  > We are going to start to switching from SVN commit emails to 
 GitHub commit

  > emails this week.  The only real change you should notice is 
 that

  > the revision number in the subject will be replaced with a git 
 hash and

  > the diff links in the email will point to GitHub.  Otherwise the

  > conte

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: Tom Stellard 
> Sent: Wednesday, October 16, 2019 3:14 PM
> To: Roman Lebedev 
> Cc: Robinson, Paul ; Shoaib Meenai
> ; Mehdi AMINI ; llvm-
> d...@lists.llvm.org; cfe-dev ; openmp-dev (openmp-
> d...@lists.llvm.org) ; LLDB Dev  d...@lists.llvm.org>
> Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> 
> On 10/16/2019 12:02 PM, Roman Lebedev wrote:
> > On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard 
> wrote:
> >>
> >> On 10/16/2019 07:31 AM, Roman Lebedev wrote:
> >>> +1, please.
> >>>
> >>> Also, putting a tag on the *first* commit in the repo,
> >>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*!
> >>>
> >>
> >> Do we need to add a tag or is `git rev-list --count HEAD`
> >> good enough?
> > Ah, interesting, that works too, better than nothing.
> > But to be noted that number is different from the `llvm-svn: <>` for
> > the current commit.
> >
> 
> This is expected.  There were a few commits that were filtered
> out in the SVN to git conversion:
> 
> https://github.com/jyknight/llvm-git-migration/blob/master/llvm-svn2git-
> monorepo.rules

Does the same tactic work for the release branches?  Or are we going to 
see some duplicate count numbers on master and the branches?  That might
be confusing.  (FYI at Sony, for release we count revs since the branch,
so the monotonic numbers on branches are generally small.)
--paulr

> 
> -Tom
> 
> >> -Tom
> > Roman
> >
> >>> Roman.
> >>>
> >>> On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev
> >>>  wrote:
> 
>  +1.  And put it in the email (subject?).  While it’s possible to
> derive a count from a hash manually, better to have it in the email in the
> first place.  You can’t rely on order-of-email-delivery to reflect order-
> of-commit.
> 
>  --paulr
> 
> 
> 
>  From: llvm-dev  On Behalf Of Shoaib
> Meenai via llvm-dev
>  Sent: Wednesday, October 16, 2019 1:42 AM
>  To: tstel...@redhat.com; Mehdi AMINI 
>  Cc: llvm-dev ; cfe-dev  d...@lists.llvm.org>; openmp-dev (openmp-...@lists.llvm.org)  d...@lists.llvm.org>; LLDB Dev 
>  Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> 
> 
> 
>  I thought we were just going to count commits on a particular branch
> and use the (branch name, commit count) tuple as our monotonic
> incrementing identifier?
> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-
> numbers-with-git
> 
> 
> 
> 
> 
>  From: cfe-dev  on behalf of cfe-dev
> 
>  Organization: Red Hat
>  Reply-To: "tstel...@redhat.com" 
>  Date: Tuesday, October 15, 2019 at 10:13 PM
>  To: Mehdi AMINI 
>  Cc: llvm-dev , cfe-dev  d...@lists.llvm.org>, "openmp-dev (openmp-...@lists.llvm.org)"  d...@lists.llvm.org>, LLDB Dev 
>  Subject: Re: [cfe-dev] Mailing list changes this week
> 
> 
> 
>  On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> 
>  On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard  > wrote:
> 
>   On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> 
>   > Hi Tom.
> 
>   >
> 
>   > One issue with this is that we don't have a clear "ordering"
> from linear revision numbers from these emails. Have we looked into
> continuing to generate our own emails per commits instead so that we
> control the format?
> 
>   >
> 
>   This actually what we are doing, we are listening for github
> commit events and
> 
>   then generating our own emails based on the data in the event.
> We can format
> 
>   the emails how ever we want, and we tried to match the current
> SVN format exactly.
> 
>  Ah great!
> 
> 
> 
>   Is the some other information you would like to have in the
> emails to show the
> 
>   ordering?
> 
>  The only thing I was looking to get was to continue to have a
> monotonic incrementing integer for the revision instead of the git hash
> alone: I don't know if `git llvm` has this feature yet but this was
> discussed a while ago (I don't remember if we just mentioned counting the
> commits in the repo from the beginning or using an invocation of `git
> describe` or something derived).
> 
> 
> 
>  We talked about using `git describe` for this, but this would require
> that we
> 
>  add tags to the master branch each time the version number was
> bumped.  We
> 
>  discussed this[1] last year, but deferred the decision, since we
> couldn't get
> 
>  consensus on the tag name.
> 
> 
> 
>  -Tom
> 
> 
> 
>  [1] https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-
> 2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQX
> KeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-
> WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=
> 
> >>>

Re: [lldb-dev] [llvm-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

[David Blaikie via lldb-dev]

On Tue, Oct 15, 2019 at 9:26 PM Mehdi AMINI via llvm-dev <
llvm-...@lists.llvm.org> wrote:

>
>
> On Tue, Oct 15, 2019 at 12:26 PM Hubert Tong via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>> I say retire it instantly.
>>>
>> +1. It has never been a real requirement to use the script. Using native
>> svn is still viable until the point of the migration.
>>
>
> It was a requirement for the "linear history" feature. With GitHub
> providing this now, I'm also +1 on retiring the tool unless there is a
> another use that can be articulated for it?
>

I believe one thing mentioned was that if the tool was required, it could
be used to enforce a do-not-branch policy. That's the thing I've seen
discussed so far. (& questions as to whether that's worth it, whether
there's other ways to enforce it, etc)

- Dave

>
> --
> Mehdi
>
>
>
>>
>>
>>>
>>> > On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev <
>>> cfe-...@lists.llvm.org> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I mentioned this in my email last week, but I wanted to start a new
>>> > thread to get everyone's input on what to do about the git-llvm script
>>> > after the GitHub migration.
>>> >
>>> > The original plan was to require the use of the git-llvm script when
>>> > committing to GitHub even after the migration was complete.
>>> > The reason we decided to do this was so that we could prevent
>>> developers
>>> > from accidentally pushing merge commits and making the history
>>> non-linear.
>>> >
>>> > Just in the last week, the GitHub team completed the "Require Linear
>>> > History" branch protection, which means we can now enforce linear
>>> > history server side and do not need the git-llvm script to do this.
>>> >
>>> > With this new development, the question I have is when should the
>>> > git-llvm script become optional?  Should we make it optional
>>> immediately,
>>> > so that developers can push directly using vanilla git from day 1, or
>>> should we
>>> > wait a few weeks/months until things have stabilized to make it
>>> optional?
>>> >
>>> > Thanks,
>>> > Tom
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ___
>>> > cfe-dev mailing list
>>> > cfe-...@lists.llvm.org
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

[David Greene via lldb-dev]

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 more analysis
> tools, if we want.

I think this makes a lot of sense.

> It would be as simple as adding CHECK lines on the execution of the
> compilation process (in CMake? Make? wrapper?) and keep the check
> files with the tests / per file.

Yep.

> I think we're on the same page regarding almost everything, but
> perhaps I haven't been clear enough on the main point, which I think
> it's pretty simple. :)

Personally, I still find source-to-asm tests to be highly valuable and I
don't think we need test-suite for that.  Such tests don't (usually)
depend on system libraries (headers may occasionally be an issue but I
would argue that the test is too fragile in that case).

So maybe we separate concerns.  Use test-suite to do the kind of
system-level testing you've discussed but still allow some tests in a
monorepo top-level directory that test across components but don't
depend on system configurations.

If people really object to a top-level monorepo test directory I guess
they could go into test-suite but that makes it much more cumbersome to
run what really should be very simple tests.

   -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[David Greene via lldb-dev]

"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.  I literally have never seen a clean check-all.  I
suspect that is because we have more components built than (most?)
others along with multiple targets.

   -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Openmp-dev] [llvm-dev] RFC: End-to-end testing

[David Blaikie via lldb-dev]

On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> 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 more analysis
> > tools, if we want.
>
> I think this makes a lot of sense.
>
> > It would be as simple as adding CHECK lines on the execution of the
> > compilation process (in CMake? Make? wrapper?) and keep the check
> > files with the tests / per file.
>
> Yep.
>
> > I think we're on the same page regarding almost everything, but
> > perhaps I haven't been clear enough on the main point, which I think
> > it's pretty simple. :)
>
> Personally, I still find source-to-asm tests to be highly valuable and I
> don't think we need test-suite for that.  Such tests don't (usually)
> depend on system libraries (headers may occasionally be an issue but I
> would argue that the test is too fragile in that case).
>
> So maybe we separate concerns.  Use test-suite to do the kind of
> system-level testing you've discussed but still allow some tests in a
> monorepo top-level directory that test across components but don't
> depend on system configurations.
>

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
configured API-wise on the MCContext - there's no way to test that
configuration on the clang boundary, so the only test that we can write is
one that tests the effect of that API/programmatic configuration done by
clang to the MCContext (function sections, for instance) - in some cases
I've just skipped the testing, in others I've written the end-to-end test
in clang (& an LLVM test for the functionality that uses llvm-mc or
similar)).


> If people really object to a top-level monorepo test directory I guess
> they could go into test-suite but that makes it much more cumbersome to
> run what really should be very simple tests.
>
>-David
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Openmp-dev] [llvm-dev] RFC: End-to-end testing

[David Blaikie via lldb-dev]

On Wed, Oct 16, 2019 at 1:09 PM Roman Lebedev via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> FWIW I'm personally cautiously non-optimistic about this,
> but maybe i'm just not seeing the whole picture of the proposal.
>
> Both checking final asm, and checking more than one layer of abstraction
> feels overreaching and very prone to breakage/too restrictful.
> Even minimal changes to the scheduling for particular CPU can cause many
> instructions to reorder.
> I'm not sure what effect that will have on middle-end pass development,
> too.
>
> A change affects these end-to-end tests, what then?
> Just blindly regenerate every affected test?
> This will be further complicated once clang isn't the only upstream
> front-end.
>

Agreed that the broader a test is, the more careful one has to be about
making it reliable in spite of other changes - sometimes that's really
difficult (if you're trying to get a particular instruction selection or
register allocation) but in others it can be fairly reliable if done
carefully to sufficiently restrict optimizations, etc. (having function
calls to external functions to act as sinks/sources for values, etc, for
instance - picking places where the output is already "optimal" and
trivially/obviously so (for whatever set of constraints you've provided -
not heroic optimizations, etc) to ensure that it's fairly stable)



- Dave


>
> Roman.
>
> On Wed, Oct 16, 2019 at 11:00 PM David Greene via cfe-dev
>  wrote:
> >
> > Renato Golin via Openmp-dev  writes:
> >
> > > We already have tests in clang that check for diagnostics, IR and
> > > other things. Expanding those can handle 99.9% of what Clang could
> > > possibly do without descending into assembly.
> >
> > I agree that for a great many things this is sufficient.
> >
> > > Assembly errors are more complicated than just "not generating VADD",
> > > and that's easier done in the TS than LIT.
> >
> > Can you elaborate?  I'm talking about very small tests targeted to
> > generate a specific instruction or small number of instructions.
> > Vectorization isn't the best example.  Something like verifying FMA
> > generation is a better example.
> >
> > -David
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 07:23 AM, Robinson, Paul wrote:
> +1.  And put it in the email (subject?).  While it’s possible to derive a 
> count from a hash manually, better to have it in the email in the first 
> place.  You can’t rely on order-of-email-delivery to reflect order-of-commit.
> 

I spent some time today looking into what it would take to add the commit
number into the email.  Implementing this will add some extra complexity to the
emailer script and add another point of failure for us.  We also
can't guarantee to always have it since at some point we may want to start using
github's standard commit emails.

I think we should just wait and see how things go without having 
a commit number in the email.  It's easy to generate the number
locally from a git hash if needed.  If it becomes a major inconvenience
to not have it in the email, we can always look at adding it in later.

-Tom

> --paulr
> 
>  
> 
> *From:* llvm-dev  *On Behalf Of *Shoaib 
> Meenai via llvm-dev
> *Sent:* Wednesday, October 16, 2019 1:42 AM
> *To:* tstel...@redhat.com; Mehdi AMINI 
> *Cc:* llvm-dev ; cfe-dev ; 
> openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 
> 
> *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> 
>  
> 
> I thought we were just going to count commits on a particular branch and use 
> the (branch name, commit count) tuple as our monotonic incrementing 
> identifier? 
> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
> 
>  
> 
>  
> 
> *From: *cfe-dev  > on behalf of cfe-dev 
> mailto:cfe-...@lists.llvm.org>>
> *Organization: *Red Hat
> *Reply-To: *"tstel...@redhat.com " 
> mailto:tstel...@redhat.com>>
> *Date: *Tuesday, October 15, 2019 at 10:13 PM
> *To: *Mehdi AMINI mailto:joker@gmail.com>>
> *Cc: *llvm-dev mailto:llvm-...@lists.llvm.org>>, 
> cfe-dev mailto:cfe-...@lists.llvm.org>>, "openmp-dev 
> (openmp-...@lists.llvm.org )" 
> mailto:openmp-...@lists.llvm.org>>, LLDB Dev 
> mailto:lldb-dev@lists.llvm.org>>
> *Subject: *Re: [cfe-dev] Mailing list changes this week
> 
>  
> 
> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> 
> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard    
> > wrote:
> 
>  On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> 
>  > Hi Tom.
> 
>  >
> 
>  > One issue with this is that we don't have a clear "ordering" from 
> linear revision numbers from these emails. Have we looked into continuing to 
> generate our own emails per commits instead so that we control the format?
> 
>  >
> 
>  This actually what we are doing, we are listening for github commit 
> events and
> 
>  then generating our own emails based on the data in the event.  We 
> can format
> 
>  the emails how ever we want, and we tried to match the current SVN 
> format exactly.
> 
> Ah great!
> 
>   
> 
>  Is the some other information you would like to have in the emails 
> to show the
> 
>  ordering?
> 
> The only thing I was looking to get was to continue to have a monotonic 
> incrementing integer for the revision instead of the git hash alone: I don't 
> know if `git llvm` has this feature yet but this was discussed a while ago (I 
> don't remember if we just mentioned counting the commits in the repo from the 
> beginning or using an invocation of `git describe` or something derived).
> 
>  
> 
> We talked about using `git describe` for this, but this would require that we
> 
> add tags to the master branch each time the version number was bumped.  We
> 
> discussed this[1] last year, but deferred the decision, since we couldn't get
> 
> consensus on the tag name.
> 
>  
> 
> -Tom
> 
>  
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=
> 
>  
> 
> -- 
> 
> Mehdi
> 
>   
> 
>  -Tom
> 
>  > Thanks,
> 
>  >
> 
>  > --
> 
>  > Mehdi
> 
>  >
> 
>  >
> 
>  >
> 
>  > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
>   > > wrote:
> 
>  >
> 
>  > Hi,
> 
>  >
> 
>  > We are going to start to switching from SVN commit emails to 
> GitHub commit
> 
>  > emails this week.  The only real change you should notice is 
> that
> 
>  > the revision number in the subject will be replaced with a git 
> hash and
> 
>  > the diff links in the email will poin

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Philip Reames via lldb-dev]

On 10/16/19 5:51 PM, Mehdi AMINI via llvm-dev wrote:



On Wed, Oct 16, 2019 at 5:46 PM Tom Stellard > wrote:


On 10/16/2019 07:23 AM, Robinson, Paul wrote:
> +1.  And put it in the email (subject?).  While it’s possible to
derive a count from a hash manually, better to have it in the
email in the first place.  You can’t rely on
order-of-email-delivery to reflect order-of-commit.
>

I spent some time today looking into what it would take to add the
commit
number into the email.  Implementing this will add some extra
complexity to the
emailer script and add another point of failure for us. We also
can't guarantee to always have it since at some point we may want
to start using
github's standard commit emails.

I think we should just wait and see how things go without having
a commit number in the email.  It's easy to generate the number
locally from a git hash if needed.  If it becomes a major
inconvenience
to not have it in the email, we can always look at adding it in later.


Having to get an up-to-date local clone and run commands to be able to 
reason about the logical relationship between commits (does this build 
failure email from a slow bot comes from before or after I landed my 
revert?) seems to me like a non-trivial workflow regression. I would 
personally be OK to increase the tooling complexity to preserve this.
+1 on this, but it's worth clarifying this is definitely not a blocker.  
Just a nice to have which can easily be done after the switch if needed.


The best way to prove or disprove this is likely do what you suggest 
though, and live through this for some time :)


--
Mehdi




-Tom

> --paulr
>
>
>
> *From:* llvm-dev mailto:llvm-dev-boun...@lists.llvm.org>> *On Behalf Of *Shoaib
Meenai via llvm-dev
> *Sent:* Wednesday, October 16, 2019 1:42 AM
> *To:* tstel...@redhat.com ; Mehdi
AMINI mailto:joker@gmail.com>>
> *Cc:* llvm-dev mailto:llvm-...@lists.llvm.org>>; cfe-dev mailto:cfe-...@lists.llvm.org>>; openmp-dev
(openmp-...@lists.llvm.org )
mailto:openmp-...@lists.llvm.org>>;
LLDB Dev mailto:lldb-dev@lists.llvm.org>>
> *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week
>
>
>
> I thought we were just going to count commits on a particular
branch and use the (branch name, commit count) tuple as our
monotonic incrementing identifier?

https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
>
>
>
>
>
> *From: *cfe-dev mailto:cfe-dev-boun...@lists.llvm.org>
>> on behalf of cfe-dev
mailto:cfe-...@lists.llvm.org>
>>
> *Organization: *Red Hat
> *Reply-To: *"tstel...@redhat.com 
>"
mailto:tstel...@redhat.com>
>>
> *Date: *Tuesday, October 15, 2019 at 10:13 PM
> *To: *Mehdi AMINI mailto:joker@gmail.com> >>
> *Cc: *llvm-dev mailto:llvm-...@lists.llvm.org> >>, cfe-dev
mailto:cfe-...@lists.llvm.org>
>>,
"openmp-dev (openmp-...@lists.llvm.org

>)" mailto:openmp-...@lists.llvm.org>
>>, LLDB Dev
mailto:lldb-dev@lists.llvm.org>
>>
> *Subject: *Re: [cfe-dev] Mailing list changes this week
>
>
>
> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
>
>     On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard
mailto:tstel...@redhat.com>
>
>
%3e>> wrote:
>
>          On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
>
>          > Hi Tom.
>
>          >
>
>          > One issue with this is that we don't have a clear
"ordering" from linear revision numbers from these emails. Have we
looked into continuing to generate our own emails per commits
instead so that we control the format?
>
>          >
>
>          This actually what we are doing, we are listening for
github commit events and
>
>          then generating our own emails based on the da

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[David Greene via lldb-dev]

> 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
> configured API-wise on the MCContext - there's no way to test that
> configuration on the clang boundary, so the only test that we can write is
> one that tests the effect of that API/programmatic configuration done by
> clang to the MCContext (function sections, for instance) - in some cases
> I've just skipped the testing, in others I've written the end-to-end test
> in clang (& an LLVM test for the functionality that uses llvm-mc or
> similar)).

I'd be totally happy putting such tests under clang.  This whole
discussion was spurred by D68230 where some noted that previous
discussion had determined we didn't want source-to-asm tests in clang
and the test update script explicitly forbade it.

If we're saying we want to reverse that decision, I'm very glad!

-David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 05:51 PM, Mehdi AMINI wrote:
> 
> 
> On Wed, Oct 16, 2019 at 5:46 PM Tom Stellard  > wrote:
> 
> On 10/16/2019 07:23 AM, Robinson, Paul wrote:
> > +1.  And put it in the email (subject?).  While it’s possible to derive 
> a count from a hash manually, better to have it in the email in the first 
> place.  You can’t rely on order-of-email-delivery to reflect order-of-commit.
> >
> 
> I spent some time today looking into what it would take to add the commit
> number into the email.  Implementing this will add some extra complexity 
> to the
> emailer script and add another point of failure for us.  We also
> can't guarantee to always have it since at some point we may want to 
> start using
> github's standard commit emails.
> 
> I think we should just wait and see how things go without having
> a commit number in the email.  It's easy to generate the number
> locally from a git hash if needed.  If it becomes a major inconvenience
> to not have it in the email, we can always look at adding it in later.
> 
> 
> Having to get an up-to-date local clone and run commands to be able to reason 
> about the logical relationship between commits (does this build failure email 
> from a slow bot comes from before or after I landed my revert?) seems to me 
> like a non-trivial workflow regression. I would personally be OK to increase 
> the tooling complexity to preserve this.
> 

There are other ways to solve this, though, for example we could have
the bots pass/fail the status checks for commits, so you could answer
the question just by clicking the link in the email and looking at
which checks have passed or failed.  And I think overall this would
be better than what we have now.

I think there may be other cases like this were problems solved using
the commit numbers may be able to be solved in different and better ways.
Part of the reason to move to GitHub is to be able to take advantage
of features like this, and I think continuing to use the commit numbers
may hold us back a little from trying new things.

> The best way to prove or disprove this is likely do what you suggest though, 
> and live through this for some time :)
> 

Right, and I'm not sure we would even be able to get the changes done in
time for the switch over anyway.

-Tom

> -- 
> Mehdi
> 
> 
> 
>  
> 
> 
> -Tom
> 
> > --paulr
> >
> > 
> >
> > *From:* llvm-dev  > *On Behalf Of *Shoaib Meenai via 
> llvm-dev
> > *Sent:* Wednesday, October 16, 2019 1:42 AM
> > *To:* tstel...@redhat.com ; Mehdi AMINI 
> mailto:joker@gmail.com>>
> > *Cc:* llvm-dev  >; cfe-dev  >; openmp-dev (openmp-...@lists.llvm.org 
> )  >; LLDB Dev  >
> > *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> >
> > 
> >
> > I thought we were just going to count commits on a particular branch 
> and use the (branch name, commit count) tuple as our monotonic incrementing 
> identifier? 
> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
> >
> > 
> >
> > 
> >
> > *From: *cfe-dev   
>  >> on behalf of cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >>
> > *Organization: *Red Hat
> > *Reply-To: *"tstel...@redhat.com  
> >" 
> mailto:tstel...@redhat.com>  >>
> > *Date: *Tuesday, October 15, 2019 at 10:13 PM
> > *To: *Mehdi AMINI mailto:joker@gmail.com> 
> >>
> > *Cc: *llvm-dev    >>, cfe-dev    >>, "openmp-dev (openmp-...@lists.llvm.org 
>   >)"    >>, LLDB Dev    >>
> > *Subject: *Re: [cfe-dev] Mailing list changes this week
> >
> > 
> >
> > On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> >
> > On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard    > 

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[David Blaikie via lldb-dev]

On Wed, Oct 16, 2019 at 6:05 PM David Greene  wrote:

> > 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
> > configured API-wise on the MCContext - there's no way to test that
> > configuration on the clang boundary, so the only test that we can write
> is
> > one that tests the effect of that API/programmatic configuration done by
> > clang to the MCContext (function sections, for instance) - in some cases
> > I've just skipped the testing, in others I've written the end-to-end test
> > in clang (& an LLVM test for the functionality that uses llvm-mc or
> > similar)).
>
> I'd be totally happy putting such tests under clang.  This whole
> discussion was spurred by D68230 where some noted that previous
> discussion had determined we didn't want source-to-asm tests in clang
> and the test update script explicitly forbade it.
>
> If we're saying we want to reverse that decision, I'm very glad!
>

Unfortunately LLVM's community is by no means a monolith, so my opinion
here doesn't mean whoever expressed their opinion there has changed their
mind.

& 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 tool to maintain/generate makes me a
bit skeptical and doubly-so if we were testing all of those end-to-end too.
(I'd expect maybe one or two sample/example end-to-end tests, to test
certain integration points, but exhaustive testing would usually be left to
narrower tests (so if you have one subsystem with three codepaths {1, 2, 3}
and another subsystem with 3 codepaths {A, B, C}, you don't test the full
combination of {1, 2, 3} X {A, B, C} (9 tests), you test each set
separately, and maybe one representative sample end-to-end (so you end up
with maybe 7-8 tests))

Possible I know so little about the vectorization issues in particular that
my thoughts on testing don't line up with the realities of that particular
domain.

- Dave


>
> -David
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev