llvm dev - Aug 2020 - LLVM deprecation policy

Oh yes, I am diffing the output of some of the tests in order to be sure
everything is the same. And running the tests, too.

I have a question about the release notes. The current version of LLVM is 10.
There are release notes for 12. What happened to poor old version 11?


At 8/7/2020 02:55 PM, David Blaikie wrote:
>On Fri, Aug 7, 2020 at 11:47 AM Paul C. Anagnostopoulos
><paul at windfall.com> wrote:
>>
>> I think I could stomach changing the tests over time, although at least
one should be left with the old punctuator. It's the "real" .td
files that scare me.
>
>Yeah, I was mostly talking about the real .td files.
>
>> Tell me more abut diffing the test files.
>
>Oh, sorry - I was mostly talking about diffing the real output of
>llvm-tblgen given the production .td files.
>
>>  I assume that the CHECK: lines are checking the important results of
each .td file, and so if all the tests still pass, things are good. Are you
suggesting some way of automating the comparison of the full outputs as part of
the build, or just in my personal workspace?
>
>I mean, sure - can do the same thing for the test files I guess. But
>yeah, I meant diffing locally as a way to validate that your changes
>to .td files had no effect in the results.
>
>>
>> At 8/7/2020 02:30 PM, David Blaikie wrote:
>> >On Fri, Aug 7, 2020 at 11:17 AM Paul C. Anagnostopoulos
>> ><paul at windfall.com> wrote:
>> >>
>> >> Oh my. You think I should patch every .td file in the system?
>> >
>> >Potentially, yes. If it's worth changing, important to figure
out the
>> >long-term migration strategy/technical debt of having two ways of
>> >doing things, etc.
>> >
>> >If this is a pure .td feature that doesn't change the resulting
output
>> >- you could validate the change (maybe updating one .td at a time)
by
>> >diffing the output of tblgen given old/new .td syntax & show
that they
>> >produce exactly the same output.
>> >
>> >> That sounds a bit scary. I wrote a new test for range lists
that tests the old and new range punctuator. And a release note is certainly in
order. But I wasn't planning to patch all 600 .td files.
>> >
>> >If it's not practical to automate (with sed, etc) and would be
a very
>> >long manual process (like 10s of hours) then - yeah, probably not
>> >worth migrating everything up-front & just leave it as-is.
>> >
>> >>
>> >> At 8/7/2020 01:56 PM, David Blaikie wrote:
>> >> >Fine by me to say the old thing's deprecated.
>> >> >
>> >> >Ideally, if it's not too painful - would be good if
you could do a
>> >> >complete migration to the new thing & remove the old
thing, to help
>> >> >keep things streamlined. (over multiple patches, with some
>> >> >notification to llvm-dev and in release notes about the
old thing
>> >> >being deprecated and encouraging folks to move to the new
thing ahead
>> >> >of the removal of the old thing)
>> >> >
>> >> >On Fri, Aug 7, 2020 at 9:47 AM Paul C. Anagnostopoulos via
llvm-dev
>> >> ><llvm-dev at lists.llvm.org> wrote:
>> >> >>
>> >> >> I checked the Developer Policy and Coding Standards
but couldn't find anything about deprecation. If I were to replace a simple
bit of syntax in TableGen, what would I say in the documentation? Was the old
syntax "deprecated"; or the new syntax "preferred"; or the
old syntax simply not documented?
>> >>
>>

On Fri, Aug 7, 2020 at 1:12 PM Paul C. Anagnostopoulos
<paul at windfall.com> wrote:
>
> Oh yes, I am diffing the output of some of the tests in order to be sure
everything is the same. And running the tests, too.
>
> I have a question about the release notes. The current version of LLVM is
10. There are release notes for 12. What happened to poor old version 11?
It's already branched for release - so patches committed to trunk
(unless they're cherrypicked to the 11 release branch) will be
released in 12.
> At 8/7/2020 02:55 PM, David Blaikie wrote:
> >On Fri, Aug 7, 2020 at 11:47 AM Paul C. Anagnostopoulos
> ><paul at windfall.com> wrote:
> >>
> >> I think I could stomach changing the tests over time, although at
least one should be left with the old punctuator. It's the "real"
.td files that scare me.
> >
> >Yeah, I was mostly talking about the real .td files.
> >
> >> Tell me more abut diffing the test files.
> >
> >Oh, sorry - I was mostly talking about diffing the real output of
> >llvm-tblgen given the production .td files.
> >
> >>  I assume that the CHECK: lines are checking the important results
of each .td file, and so if all the tests still pass, things are good. Are you
suggesting some way of automating the comparison of the full outputs as part of
the build, or just in my personal workspace?
> >
> >I mean, sure - can do the same thing for the test files I guess. But
> >yeah, I meant diffing locally as a way to validate that your changes
> >to .td files had no effect in the results.
> >
> >>
> >> At 8/7/2020 02:30 PM, David Blaikie wrote:
> >> >On Fri, Aug 7, 2020 at 11:17 AM Paul C. Anagnostopoulos
> >> ><paul at windfall.com> wrote:
> >> >>
> >> >> Oh my. You think I should patch every .td file in the
system?
> >> >
> >> >Potentially, yes. If it's worth changing, important to
figure out the
> >> >long-term migration strategy/technical debt of having two ways
of
> >> >doing things, etc.
> >> >
> >> >If this is a pure .td feature that doesn't change the
resulting output
> >> >- you could validate the change (maybe updating one .td at a
time) by
> >> >diffing the output of tblgen given old/new .td syntax &
show that they
> >> >produce exactly the same output.
> >> >
> >> >> That sounds a bit scary. I wrote a new test for range
lists that tests the old and new range punctuator. And a release note is
certainly in order. But I wasn't planning to patch all 600 .td files.
> >> >
> >> >If it's not practical to automate (with sed, etc) and
would be a very
> >> >long manual process (like 10s of hours) then - yeah, probably
not
> >> >worth migrating everything up-front & just leave it as-is.
> >> >
> >> >>
> >> >> At 8/7/2020 01:56 PM, David Blaikie wrote:
> >> >> >Fine by me to say the old thing's deprecated.
> >> >> >
> >> >> >Ideally, if it's not too painful - would be good
if you could do a
> >> >> >complete migration to the new thing & remove the
old thing, to help
> >> >> >keep things streamlined. (over multiple patches, with
some
> >> >> >notification to llvm-dev and in release notes about
the old thing
> >> >> >being deprecated and encouraging folks to move to the
new thing ahead
> >> >> >of the removal of the old thing)
> >> >> >
> >> >> >On Fri, Aug 7, 2020 at 9:47 AM Paul C.
Anagnostopoulos via llvm-dev
> >> >> ><llvm-dev at lists.llvm.org> wrote:
> >> >> >>
> >> >> >> I checked the Developer Policy and Coding
Standards but couldn't find anything about deprecation. If I were to replace
a simple bit of syntax in TableGen, what would I say in the documentation? Was
the old syntax "deprecated"; or the new syntax "preferred";
or the old syntax simply not documented?
> >> >>
> >>
>

Is it okay to edit the version 12 release notes, or is there a release maven to
whom such changes should be sent?

At 8/7/2020 04:15 PM, David Blaikie wrote:
>> I have a question about the release notes. The current version of LLVM
is 10. There are release notes for 12. What happened to poor old version 11?
>
>It's already branched for release - so patches committed to trunk
>(unless they're cherrypicked to the 11 release branch) will be
>released in 12.

----------------------------------------------------------------
Windfall               Paul C. Anagnostopoulos 
      ----------------------------------------------------------
   Software            978 369-0839
                             www.windfall.com
----------------------------------------------------------------
My life has been filled with calamities,
some of which actually happened.
---Mark Twain 

Guga 'mzimba, sala 'nhliziyo

On Fri, Aug 7, 2020 at 10:12 PM Paul C. Anagnostopoulos via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Oh yes, I am diffing the output of some of the tests in order to be sure
everything is the same. And running the tests, too.
Don't just diff the tests -- diff the .inc files that are generated as
part of the real LLVM build. Or take hashes (shaXsum or whatever)
before and after. This really isn't too difficult to do, by the way:

find $builddir -name \*.inc -exec sha256sum {} \;

Do that before and after your change, and diff it -- you really should
be seeing zero changes for a frontend-only change to TableGen like
that.

Cheers,
Nicolai

>
> I have a question about the release notes. The current version of LLVM is
10. There are release notes for 12. What happened to poor old version 11?
>
>
> At 8/7/2020 02:55 PM, David Blaikie wrote:
> >On Fri, Aug 7, 2020 at 11:47 AM Paul C. Anagnostopoulos
> ><paul at windfall.com> wrote:
> >>
> >> I think I could stomach changing the tests over time, although at
least one should be left with the old punctuator. It's the "real"
.td files that scare me.
> >
> >Yeah, I was mostly talking about the real .td files.
> >
> >> Tell me more abut diffing the test files.
> >
> >Oh, sorry - I was mostly talking about diffing the real output of
> >llvm-tblgen given the production .td files.
> >
> >>  I assume that the CHECK: lines are checking the important results
of each .td file, and so if all the tests still pass, things are good. Are you
suggesting some way of automating the comparison of the full outputs as part of
the build, or just in my personal workspace?
> >
> >I mean, sure - can do the same thing for the test files I guess. But
> >yeah, I meant diffing locally as a way to validate that your changes
> >to .td files had no effect in the results.
> >
> >>
> >> At 8/7/2020 02:30 PM, David Blaikie wrote:
> >> >On Fri, Aug 7, 2020 at 11:17 AM Paul C. Anagnostopoulos
> >> ><paul at windfall.com> wrote:
> >> >>
> >> >> Oh my. You think I should patch every .td file in the
system?
> >> >
> >> >Potentially, yes. If it's worth changing, important to
figure out the
> >> >long-term migration strategy/technical debt of having two ways
of
> >> >doing things, etc.
> >> >
> >> >If this is a pure .td feature that doesn't change the
resulting output
> >> >- you could validate the change (maybe updating one .td at a
time) by
> >> >diffing the output of tblgen given old/new .td syntax &
show that they
> >> >produce exactly the same output.
> >> >
> >> >> That sounds a bit scary. I wrote a new test for range
lists that tests the old and new range punctuator. And a release note is
certainly in order. But I wasn't planning to patch all 600 .td files.
> >> >
> >> >If it's not practical to automate (with sed, etc) and
would be a very
> >> >long manual process (like 10s of hours) then - yeah, probably
not
> >> >worth migrating everything up-front & just leave it as-is.
> >> >
> >> >>
> >> >> At 8/7/2020 01:56 PM, David Blaikie wrote:
> >> >> >Fine by me to say the old thing's deprecated.
> >> >> >
> >> >> >Ideally, if it's not too painful - would be good
if you could do a
> >> >> >complete migration to the new thing & remove the
old thing, to help
> >> >> >keep things streamlined. (over multiple patches, with
some
> >> >> >notification to llvm-dev and in release notes about
the old thing
> >> >> >being deprecated and encouraging folks to move to the
new thing ahead
> >> >> >of the removal of the old thing)
> >> >> >
> >> >> >On Fri, Aug 7, 2020 at 9:47 AM Paul C.
Anagnostopoulos via llvm-dev
> >> >> ><llvm-dev at lists.llvm.org> wrote:
> >> >> >>
> >> >> >> I checked the Developer Policy and Coding
Standards but couldn't find anything about deprecation. If I were to replace
a simple bit of syntax in TableGen, what would I say in the documentation? Was
the old syntax "deprecated"; or the new syntax "preferred";
or the old syntax simply not documented?
> >> >>
> >>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

Excellent idea, thanks. 

At 8/8/2020 10:33 AM, Nicolai Hähnle wrote:
>On Fri, Aug 7, 2020 at 10:12 PM Paul C. Anagnostopoulos via llvm-dev
><llvm-dev at lists.llvm.org> wrote:
>> Oh yes, I am diffing the output of some of the tests in order to be
sure everything is the same. And running the tests, too.
>
>Don't just diff the tests -- diff the .inc files that are generated as
>part of the real LLVM build. Or take hashes (shaXsum or whatever)
>before and after. This really isn't too difficult to do, by the way:
>
>find $builddir -name \*.inc -exec sha256sum {} \;
>
>Do that before and after your change, and diff it -- you really should
>be seeing zero changes for a frontend-only change to TableGen like
>that.
>
>Cheers,
>Nicolai
>
>
>>
>> I have a question about the release notes. The current version of LLVM
is 10. There are release notes for 12. What happened to poor old version 11?
>>
>>
>> At 8/7/2020 02:55 PM, David Blaikie wrote:
>> >On Fri, Aug 7, 2020 at 11:47 AM Paul C. Anagnostopoulos
>> ><paul at windfall.com> wrote:
>> >>
>> >> I think I could stomach changing the tests over time, although
at least one should be left with the old punctuator. It's the
"real" .td files that scare me.
>> >
>> >Yeah, I was mostly talking about the real .td files.
>> >
>> >> Tell me more abut diffing the test files.
>> >
>> >Oh, sorry - I was mostly talking about diffing the real output of
>> >llvm-tblgen given the production .td files.
>> >
>> >>  I assume that the CHECK: lines are checking the important
results of each .td file, and so if all the tests still pass, things are good.
Are you suggesting some way of automating the comparison of the full outputs as
part of the build, or just in my personal workspace?
>> >
>> >I mean, sure - can do the same thing for the test files I guess.
But
>> >yeah, I meant diffing locally as a way to validate that your
changes
>> >to .td files had no effect in the results.
>> >
>> >>
>> >> At 8/7/2020 02:30 PM, David Blaikie wrote:
>> >> >On Fri, Aug 7, 2020 at 11:17 AM Paul C. Anagnostopoulos
>> >> ><paul at windfall.com> wrote:
>> >> >>
>> >> >> Oh my. You think I should patch every .td file in the
system?
>> >> >
>> >> >Potentially, yes. If it's worth changing, important to
figure out the
>> >> >long-term migration strategy/technical debt of having two
ways of
>> >> >doing things, etc.
>> >> >
>> >> >If this is a pure .td feature that doesn't change the
resulting output
>> >> >- you could validate the change (maybe updating one .td at
a time) by
>> >> >diffing the output of tblgen given old/new .td syntax
& show that they
>> >> >produce exactly the same output.
>> >> >
>> >> >> That sounds a bit scary. I wrote a new test for range
lists that tests the old and new range punctuator. And a release note is
certainly in order. But I wasn't planning to patch all 600 .td files.
>> >> >
>> >> >If it's not practical to automate (with sed, etc) and
would be a very
>> >> >long manual process (like 10s of hours) then - yeah,
probably not
>> >> >worth migrating everything up-front & just leave it
as-is.
>> >> >
>> >> >>
>> >> >> At 8/7/2020 01:56 PM, David Blaikie wrote:
>> >> >> >Fine by me to say the old thing's deprecated.
>> >> >> >
>> >> >> >Ideally, if it's not too painful - would be
good if you could do a
>> >> >> >complete migration to the new thing & remove
the old thing, to help
>> >> >> >keep things streamlined. (over multiple patches,
with some
>> >> >> >notification to llvm-dev and in release notes
about the old thing
>> >> >> >being deprecated and encouraging folks to move to
the new thing ahead
>> >> >> >of the removal of the old thing)
>> >> >> >
>> >> >> >On Fri, Aug 7, 2020 at 9:47 AM Paul C.
Anagnostopoulos via llvm-dev
>> >> >> ><llvm-dev at lists.llvm.org> wrote:
>> >> >> >>
>> >> >> >> I checked the Developer Policy and Coding
Standards but couldn't find anything about deprecation. If I were to replace
a simple bit of syntax in TableGen, what would I say in the documentation? Was
the old syntax "deprecated"; or the new syntax "preferred";
or the old syntax simply not documented?
>> >> >>
>> >>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>-- 
>Lerne, wie die Welt wirklich ist,
>aber vergiss niemals, wie sie sein sollte.