llvm dev - Mar 2016 - [cfe-dev] [3.8 Release] Please write release notes!

Dear lots of people,

The first comments on the 3.7 release expressed surprise that there
were no changes to the X86 or ARM targets. There had of course been a
lot of hard work and many changes, but none of it was mentioned in the
release notes.

Please help make the release notes more comprehensive this time. The
notes are of course not as important as the actual code, but they do
get read, and they are a good way of telling users about all the hard
work you have done in the past six months.

If you made any changes in the 3.8 time span that might be worth
mentioning, please add them to the release notes --- it does not have
to be big-ticket items. If you saw someone else commit something
interesting, prod them to write a note about it.

The 3.8-rc2 notes can be seen at [1]. To add something, commit it
directly to the branch, or if you prefer, send me a patch or even just
an email with some text. I would be very happy if we can get these
into good shape by the beginning of next week.


Some things that might be worth mentioning, in no particular order:
(based partially on Alex Bradbury's LLVM Weekly; thanks!)

- Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
please write something about your target.

- Eric: should the new C API Changes part of the developer policy be
pointed out? Maybe in relation to where we mention changes to the C
API?

- David: can you write something about the new IR for exception
handling? Maybe just point into the ExceptionHandling doc?

- Alex L: I've seen a lot of MIR patches but don't know the status.
Anything to mention in the release notes?

- Dylan: should we mention the new AVR target, or is it too early?

- Richard: anything on the C++ front? What's the status on coroutines?

- Jonathan and other OpenMP folks: it's no longer behind a flag; would
be great to get some notes on this.

- Artem: there's been a bunch of CUDA patches. Anything that should be
mentioned in the release notes?

- Jordan & Anna: any new checkers that should be mentioned?

- Chih-Hung: should the notes mention the emutls-style TLS model?

- Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
should mention that?

.. tell me what I missed :-)

Thanks,
Hans

 [1]. http://llvm.org/pre-releases/3.8.0/#rc2.

Hans,

It might be worth putting a mention in the clang release notes about autoconf
being deprecated. I’ve attached a patch.

Thanks,
-Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-release-note-cmake.diff
Type: application/octet-stream
Size: 649 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160212/3bc4b68d/attachment.obj>
-------------- next part --------------
> On Feb 11, 2016, at 4:16 PM, Hans Wennborg via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Dear lots of people,
> 
> The first comments on the 3.7 release expressed surprise that there
> were no changes to the X86 or ARM targets. There had of course been a
> lot of hard work and many changes, but none of it was mentioned in the
> release notes.
> 
> Please help make the release notes more comprehensive this time. The
> notes are of course not as important as the actual code, but they do
> get read, and they are a good way of telling users about all the hard
> work you have done in the past six months.
> 
> If you made any changes in the 3.8 time span that might be worth
> mentioning, please add them to the release notes --- it does not have
> to be big-ticket items. If you saw someone else commit something
> interesting, prod them to write a note about it.
> 
> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
> directly to the branch, or if you prefer, send me a patch or even just
> an email with some text. I would be very happy if we can get these
> into good shape by the beginning of next week.
> 
> 
> Some things that might be worth mentioning, in no particular order:
> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
> 
> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
> please write something about your target.
> 
> - Eric: should the new C API Changes part of the developer policy be
> pointed out? Maybe in relation to where we mention changes to the C
> API?
> 
> - David: can you write something about the new IR for exception
> handling? Maybe just point into the ExceptionHandling doc?
> 
> - Alex L: I've seen a lot of MIR patches but don't know the status.
> Anything to mention in the release notes?
> 
> - Dylan: should we mention the new AVR target, or is it too early?
> 
> - Richard: anything on the C++ front? What's the status on coroutines?
> 
> - Jonathan and other OpenMP folks: it's no longer behind a flag; would
> be great to get some notes on this.
> 
> - Artem: there's been a bunch of CUDA patches. Anything that should be
> mentioned in the release notes?
> 
> - Jordan & Anna: any new checkers that should be mentioned?
> 
> - Chih-Hung: should the notes mention the emutls-style TLS model?
> 
> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
> should mention that?
> 
> .. tell me what I missed :-)
> 
> Thanks,
> Hans
> 
> [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Thanks! r260718.

On Fri, Feb 12, 2016 at 12:22 PM, Chris Bieneman <beanz at apple.com>
wrote:
> Hans,
>
> It might be worth putting a mention in the clang release notes about
autoconf being deprecated. I’ve attached a patch.
>
> Thanks,
> -Chris
>
>
>> On Feb 11, 2016, at 4:16 PM, Hans Wennborg via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> Dear lots of people,
>>
>> The first comments on the 3.7 release expressed surprise that there
>> were no changes to the X86 or ARM targets. There had of course been a
>> lot of hard work and many changes, but none of it was mentioned in the
>> release notes.
>>
>> Please help make the release notes more comprehensive this time. The
>> notes are of course not as important as the actual code, but they do
>> get read, and they are a good way of telling users about all the hard
>> work you have done in the past six months.
>>
>> If you made any changes in the 3.8 time span that might be worth
>> mentioning, please add them to the release notes --- it does not have
>> to be big-ticket items. If you saw someone else commit something
>> interesting, prod them to write a note about it.
>>
>> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
>> directly to the branch, or if you prefer, send me a patch or even just
>> an email with some text. I would be very happy if we can get these
>> into good shape by the beginning of next week.
>>
>>
>> Some things that might be worth mentioning, in no particular order:
>> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
>>
>> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
>> please write something about your target.
>>
>> - Eric: should the new C API Changes part of the developer policy be
>> pointed out? Maybe in relation to where we mention changes to the C
>> API?
>>
>> - David: can you write something about the new IR for exception
>> handling? Maybe just point into the ExceptionHandling doc?
>>
>> - Alex L: I've seen a lot of MIR patches but don't know the
status.
>> Anything to mention in the release notes?
>>
>> - Dylan: should we mention the new AVR target, or is it too early?
>>
>> - Richard: anything on the C++ front? What's the status on
coroutines?
>>
>> - Jonathan and other OpenMP folks: it's no longer behind a flag;
would
>> be great to get some notes on this.
>>
>> - Artem: there's been a bunch of CUDA patches. Anything that should
be
>> mentioned in the release notes?
>>
>> - Jordan & Anna: any new checkers that should be mentioned?
>>
>> - Chih-Hung: should the notes mention the emutls-style TLS model?
>>
>> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
>> should mention that?
>>
>> .. tell me what I missed :-)
>>
>> Thanks,
>> Hans
>>
>> [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Dear lots of people,
>
> The first comments on the 3.7 release expressed surprise that there
> were no changes to the X86 or ARM targets. There had of course been a
> lot of hard work and many changes, but none of it was mentioned in the
> release notes.
>
> Please help make the release notes more comprehensive this time. The
> notes are of course not as important as the actual code, but they do
> get read, and they are a good way of telling users about all the hard
> work you have done in the past six months.
>
> If you made any changes in the 3.8 time span that might be worth
> mentioning, please add them to the release notes --- it does not have
> to be big-ticket items. If you saw someone else commit something
> interesting, prod them to write a note about it.
>
> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
> directly to the branch, or if you prefer, send me a patch or even just
> an email with some text. I would be very happy if we can get these
> into good shape by the beginning of next week.
>
>
> Some things that might be worth mentioning, in no particular order:
> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
>
> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
> please write something about your target.
>
> - Eric: should the new C API Changes part of the developer policy be
> pointed out? Maybe in relation to where we mention changes to the C
> API?
>
> - David: can you write something about the new IR for exception
> handling? Maybe just point into the ExceptionHandling doc?
>
> - Alex L: I've seen a lot of MIR patches but don't know the status.
> Anything to mention in the release notes?
>
> - Dylan: should we mention the new AVR target, or is it too early?
>
> - Richard: anything on the C++ front? What's the status on coroutines?
>
Neither coroutines nor concepts are sufficiently far progressed to be worth
mentioning. However, we have implemented
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html in 3.8,
which is a backwards-incompatible semantics change and should definitely be
noted.

> - Jonathan and other OpenMP folks: it's no longer behind a flag; would
> be great to get some notes on this.
>
> - Artem: there's been a bunch of CUDA patches. Anything that should be
> mentioned in the release notes?
>
> - Jordan & Anna: any new checkers that should be mentioned?
>
> - Chih-Hung: should the notes mention the emutls-style TLS model?
>
> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
> should mention that?
>
> .. tell me what I missed :-)
>
> Thanks,
> Hans
>
>  [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160212/c4843084/attachment.html>

About emutls mode, maybe the release note can mention the new
flag -femulated-tls?
I have a short description in UsersManual.rst,
http://reviews.llvm.org/D10524#11beea47.
Thanks.


On Fri, Feb 12, 2016 at 12:35 PM, Richard Smith <richard at metafoo.co.uk>
wrote:
> On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Dear lots of people,
>>
>> The first comments on the 3.7 release expressed surprise that there
>> were no changes to the X86 or ARM targets. There had of course been a
>> lot of hard work and many changes, but none of it was mentioned in the
>> release notes.
>>
>> Please help make the release notes more comprehensive this time. The
>> notes are of course not as important as the actual code, but they do
>> get read, and they are a good way of telling users about all the hard
>> work you have done in the past six months.
>>
>> If you made any changes in the 3.8 time span that might be worth
>> mentioning, please add them to the release notes --- it does not have
>> to be big-ticket items. If you saw someone else commit something
>> interesting, prod them to write a note about it.
>>
>> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
>> directly to the branch, or if you prefer, send me a patch or even just
>> an email with some text. I would be very happy if we can get these
>> into good shape by the beginning of next week.
>>
>>
>> Some things that might be worth mentioning, in no particular order:
>> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
>>
>> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
>> please write something about your target.
>>
>> - Eric: should the new C API Changes part of the developer policy be
>> pointed out? Maybe in relation to where we mention changes to the C
>> API?
>>
>> - David: can you write something about the new IR for exception
>> handling? Maybe just point into the ExceptionHandling doc?
>>
>> - Alex L: I've seen a lot of MIR patches but don't know the
status.
>> Anything to mention in the release notes?
>>
>> - Dylan: should we mention the new AVR target, or is it too early?
>>
>> - Richard: anything on the C++ front? What's the status on
coroutines?
>>
>
> Neither coroutines nor concepts are sufficiently far progressed to be
> worth mentioning. However, we have implemented
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html in
> 3.8, which is a backwards-incompatible semantics change and should
> definitely be noted.
>
>
>> - Jonathan and other OpenMP folks: it's no longer behind a flag;
would
>> be great to get some notes on this.
>>
>> - Artem: there's been a bunch of CUDA patches. Anything that should
be
>> mentioned in the release notes?
>>
>> - Jordan & Anna: any new checkers that should be mentioned?
>>
>> - Chih-Hung: should the notes mention the emutls-style TLS model?
>>
>> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
>> should mention that?
>>
>> .. tell me what I missed :-)
>>
>> Thanks,
>> Hans
>>
>>  [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160212/c3698f8b/attachment.html>

HI Hans,

- The Kaleidoscope tutorials have been updated to use the ORC JIT APIs.

- ORC now has a basic set of C bindings.

I believe the ORC remote JIT support actually went in before 3.8 branched
too, but it's still experimental. I'm not sure I'd mention it in the
release notes.

Cheers,
Lang.


On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg <hans at chromium.org>
wrote:
> Dear lots of people,
>
> The first comments on the 3.7 release expressed surprise that there
> were no changes to the X86 or ARM targets. There had of course been a
> lot of hard work and many changes, but none of it was mentioned in the
> release notes.
>
> Please help make the release notes more comprehensive this time. The
> notes are of course not as important as the actual code, but they do
> get read, and they are a good way of telling users about all the hard
> work you have done in the past six months.
>
> If you made any changes in the 3.8 time span that might be worth
> mentioning, please add them to the release notes --- it does not have
> to be big-ticket items. If you saw someone else commit something
> interesting, prod them to write a note about it.
>
> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
> directly to the branch, or if you prefer, send me a patch or even just
> an email with some text. I would be very happy if we can get these
> into good shape by the beginning of next week.
>
>
> Some things that might be worth mentioning, in no particular order:
> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
>
> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
> please write something about your target.
>
> - Eric: should the new C API Changes part of the developer policy be
> pointed out? Maybe in relation to where we mention changes to the C
> API?
>
> - David: can you write something about the new IR for exception
> handling? Maybe just point into the ExceptionHandling doc?
>
> - Alex L: I've seen a lot of MIR patches but don't know the status.
> Anything to mention in the release notes?
>
> - Dylan: should we mention the new AVR target, or is it too early?
>
> - Richard: anything on the C++ front? What's the status on coroutines?
>
> - Jonathan and other OpenMP folks: it's no longer behind a flag; would
> be great to get some notes on this.
>
> - Artem: there's been a bunch of CUDA patches. Anything that should be
> mentioned in the release notes?
>
> - Jordan & Anna: any new checkers that should be mentioned?
>
> - Chih-Hung: should the notes mention the emutls-style TLS model?
>
> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
> should mention that?
>
> .. tell me what I missed :-)
>
> Thanks,
> Hans
>
>  [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160212/5bcc1e35/attachment.html>

Hi Hans,

CUDA support:

Clang has experimental support for end-to-end CUDA compilation now:
* driver now detects CUDA installation, creates host and device compilation
pipelines,
   links device-side code with appropriate CUDA bitcode and produces single
object file
   with host and GPU code.
* Implemented target attribute-based function overloading which allows
clang to compile
   CUDA sources without splitting them into separate host/device TUs.


On Fri, Feb 12, 2016 at 3:32 PM, Lang Hames <lhames at gmail.com> wrote:
> HI Hans,
>
> - The Kaleidoscope tutorials have been updated to use the ORC JIT APIs.
>
> - ORC now has a basic set of C bindings.
>
> I believe the ORC remote JIT support actually went in before 3.8 branched
> too, but it's still experimental. I'm not sure I'd mention it
in the
> release notes.
>
> Cheers,
> Lang.
>
>
> On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg <hans at chromium.org>
wrote:
>
>> Dear lots of people,
>>
>> The first comments on the 3.7 release expressed surprise that there
>> were no changes to the X86 or ARM targets. There had of course been a
>> lot of hard work and many changes, but none of it was mentioned in the
>> release notes.
>>
>> Please help make the release notes more comprehensive this time. The
>> notes are of course not as important as the actual code, but they do
>> get read, and they are a good way of telling users about all the hard
>> work you have done in the past six months.
>>
>> If you made any changes in the 3.8 time span that might be worth
>> mentioning, please add them to the release notes --- it does not have
>> to be big-ticket items. If you saw someone else commit something
>> interesting, prod them to write a note about it.
>>
>> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
>> directly to the branch, or if you prefer, send me a patch or even just
>> an email with some text. I would be very happy if we can get these
>> into good shape by the beginning of next week.
>>
>>
>> Some things that might be worth mentioning, in no particular order:
>> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
>>
>> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
>> please write something about your target.
>>
>> - Eric: should the new C API Changes part of the developer policy be
>> pointed out? Maybe in relation to where we mention changes to the C
>> API?
>>
>> - David: can you write something about the new IR for exception
>> handling? Maybe just point into the ExceptionHandling doc?
>>
>> - Alex L: I've seen a lot of MIR patches but don't know the
status.
>> Anything to mention in the release notes?
>>
>> - Dylan: should we mention the new AVR target, or is it too early?
>>
>> - Richard: anything on the C++ front? What's the status on
coroutines?
>>
>> - Jonathan and other OpenMP folks: it's no longer behind a flag;
would
>> be great to get some notes on this.
>>
>> - Artem: there's been a bunch of CUDA patches. Anything that should
be
>> mentioned in the release notes?
>>
>> - Jordan & Anna: any new checkers that should be mentioned?
>>
>> - Chih-Hung: should the notes mention the emutls-style TLS model?
>>
>> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
>> should mention that?
>>
>> .. tell me what I missed :-)
>>
>> Thanks,
>> Hans
>>
>>  [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
>>
>
>

-- 
--Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160216/0519e1e7/attachment.html>

On 2/11/2016 6:16 PM, Hans Wennborg wrote:
>
> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
> please write something about your target.
Hi Hans,
Here's the note about Hexagon:

In addition to general code size and performance improvements, Hexagon 
target now has basic support for Hexagon V60 architecture and Hexagon 
Vector Extensions (HVX).

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

Thanks! r260991.

On Fri, Feb 12, 2016 at 3:32 PM, Lang Hames <lhames at gmail.com>
wrote:
> HI Hans,
>
> - The Kaleidoscope tutorials have been updated to use the ORC JIT APIs.
>
> - ORC now has a basic set of C bindings.
>
> I believe the ORC remote JIT support actually went in before 3.8 branched
> too, but it's still experimental. I'm not sure I'd mention it
in the release
> notes.
>
> Cheers,
> Lang.
>
>
> On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg <hans at chromium.org>
wrote:
>>
>> Dear lots of people,
>>
>> The first comments on the 3.7 release expressed surprise that there
>> were no changes to the X86 or ARM targets. There had of course been a
>> lot of hard work and many changes, but none of it was mentioned in the
>> release notes.
>>
>> Please help make the release notes more comprehensive this time. The
>> notes are of course not as important as the actual code, but they do
>> get read, and they are a good way of telling users about all the hard
>> work you have done in the past six months.
>>
>> If you made any changes in the 3.8 time span that might be worth
>> mentioning, please add them to the release notes --- it does not have
>> to be big-ticket items. If you saw someone else commit something
>> interesting, prod them to write a note about it.
>>
>> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
>> directly to the branch, or if you prefer, send me a patch or even just
>> an email with some text. I would be very happy if we can get these
>> into good shape by the beginning of next week.
>>
>>
>> Some things that might be worth mentioning, in no particular order:
>> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
>>
>> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
>> please write something about your target.
>>
>> - Eric: should the new C API Changes part of the developer policy be
>> pointed out? Maybe in relation to where we mention changes to the C
>> API?
>>
>> - David: can you write something about the new IR for exception
>> handling? Maybe just point into the ExceptionHandling doc?
>>
>> - Alex L: I've seen a lot of MIR patches but don't know the
status.
>> Anything to mention in the release notes?
>>
>> - Dylan: should we mention the new AVR target, or is it too early?
>>
>> - Richard: anything on the C++ front? What's the status on
coroutines?
>>
>> - Jonathan and other OpenMP folks: it's no longer behind a flag;
would
>> be great to get some notes on this.
>>
>> - Artem: there's been a bunch of CUDA patches. Anything that should
be
>> mentioned in the release notes?
>>
>> - Jordan & Anna: any new checkers that should be mentioned?
>>
>> - Chih-Hung: should the notes mention the emutls-style TLS model?
>>
>> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
>> should mention that?
>>
>> .. tell me what I missed :-)
>>
>> Thanks,
>> Hans
>>
>>  [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
>
>

On Tue, Feb 16, 2016 at 11:12 AM, Krzysztof Parzyszek
<kparzysz at codeaurora.org> wrote:
> On 2/11/2016 6:16 PM, Hans Wennborg wrote:
>>
>>
>> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
>> please write something about your target.
>
>
> Hi Hans,
> Here's the note about Hexagon:
>
> In addition to general code size and performance improvements, Hexagon
> target now has basic support for Hexagon V60 architecture and Hexagon
Vector
> Extensions (HVX).
Thanks! r260999.

On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Dear lots of people,
>
> The first comments on the 3.7 release expressed surprise that there
> were no changes to the X86 or ARM targets. There had of course been a
> lot of hard work and many changes, but none of it was mentioned in the
> release notes.
>
> Please help make the release notes more comprehensive this time. The
> notes are of course not as important as the actual code, but they do
> get read, and they are a good way of telling users about all the hard
> work you have done in the past six months.
>
> If you made any changes in the 3.8 time span that might be worth
> mentioning, please add them to the release notes --- it does not have
> to be big-ticket items. If you saw someone else commit something
> interesting, prod them to write a note about it.
>
> The 3.8-rc2 notes can be seen at [1]. To add something, commit it
> directly to the branch, or if you prefer, send me a patch or even just
> an email with some text. I would be very happy if we can get these
> into good shape by the beginning of next week.
>
>
> Some things that might be worth mentioning, in no particular order:
> (based partially on Alex Bradbury's LLVM Weekly; thanks!)
>
> - Intel, ARM, PowerPC, MIPS, SPARC, Hexagon, ..., target maintainers,
> please write something about your target.
>
> - Eric: should the new C API Changes part of the developer policy be
> pointed out? Maybe in relation to where we mention changes to the C
> API?
>
> - David: can you write something about the new IR for exception
> handling? Maybe just point into the ExceptionHandling doc?
>
MSVC compatible exception handling has been completely overhauled.
New instructions have been introduced to facilitate this:
http://llvm.org/docs/ExceptionHandling.html#new-exception-handling-instructions

While we have done our best to test this feature thoroughly, it would not
be completely surprising if there were a few lingering issues that early
adopters might bump into.

>
> - Alex L: I've seen a lot of MIR patches but don't know the status.
> Anything to mention in the release notes?
>
> - Dylan: should we mention the new AVR target, or is it too early?
>
> - Richard: anything on the C++ front? What's the status on coroutines?
>
> - Jonathan and other OpenMP folks: it's no longer behind a flag; would
> be great to get some notes on this.
>
> - Artem: there's been a bunch of CUDA patches. Anything that should be
> mentioned in the release notes?
>
> - Jordan & Anna: any new checkers that should be mentioned?
>
> - Chih-Hung: should the notes mention the emutls-style TLS model?
>
> - Lang: you did a lot of work on the Kalidoscope tutorial. Maybe we
> should mention that?
>
> .. tell me what I missed :-)
>
> Thanks,
> Hans
>
>  [1]. http://llvm.org/pre-releases/3.8.0/#rc2.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160217/1904d371/attachment.html>

On Wed, Feb 17, 2016 at 9:44 AM, David Majnemer
<david.majnemer at gmail.com> wrote:
>> - David: can you write something about the new IR for exception
>> handling? Maybe just point into the ExceptionHandling doc?
>
>
> MSVC compatible exception handling has been completely overhauled.
> New instructions have been introduced to facilitate this:
>
http://llvm.org/docs/ExceptionHandling.html#new-exception-handling-instructions
>
> While we have done our best to test this feature thoroughly, it would not
be
> completely surprising if there were a few lingering issues that early
> adopters might bump into.
Thanks! r261116.

If you were thinking about writing a note for 3.8 but didn't get
around to it yet, this is the final reminder.

(In particular, the notes for X86 and PowerPC could use some attention.)

Thanks,
Hans

On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg <hans at chromium.org>
wrote:
> Dear lots of people,
>
> The first comments on the 3.7 release expressed surprise that there
> were no changes to the X86 or ARM targets. There had of course been a
> lot of hard work and many changes, but none of it was mentioned in the
> release notes.
>
> Please help make the release notes more comprehensive this time. The
> notes are of course not as important as the actual code, but they do
> get read, and they are a good way of telling users about all the hard
> work you have done in the past six months.
>
> If you made any changes in the 3.8 time span that might be worth
> mentioning, please add them to the release notes --- it does not have
> to be big-ticket items. If you saw someone else commit something
> interesting, prod them to write a note about it.

>
>
> - Eric: should the new C API Changes part of the developer policy be
> pointed out? Maybe in relation to where we mention changes to the C
> API?
>
>
Good point, how about this:

----

We have documented our C API stability guarantees for both development and
release branches, as well as documented how to extend the C API. Please see
the developer documentation at
http://llvm.org/docs/DeveloperPolicy.html#c-api-changes for more
information.

----

Or if we feel like being verbose you can add the following from my original
email to the release notes:

----

Stability Guarantees:

The C API is, in general, a “best effort” for stability. This means that
we’ll make every attempt to keep the C API stable, but that stability will
be limited by the abstractness of the interface and the stability of the C
++ API that it wraps. In practice, this means that things like “create
debug info” or “create this type of instruction” is likely to be less
stable than “take this IR file and JIT it for my current machine”.
Release stability:
We won’t break the C API on the release branch with patches that go on that
branch - in general.
Exception: If we fix an unintentional C API break that will keep us
consistent with both the previous and next release.

Including new things into the API:

We’re going to adopt a policy of “if a particular LLVM subcomponent has a C
API already included, then expanding that API is acceptable”, but we’re
also going to institute a better policy of “please test the API that you’ve
just expanded”. Hopefully this will get the C API better tested as time
goes on to remove accidental breakage so that any time we break the C API we
know about it.

Adding C API for subcomponents that don’t currently have one is also fine,
and the details of how best to do that should be discussed onthe mailing
list as they come up.

Documentation:

We’re going to document this policy in the developer documentation. In
addition, any changes to the C API will require documentation in therelease
notes so that it’s clear to external users who do not follow the project
how the C API is changing and evolving.

What we expect this means in practice is that APIs like libLTO and other
APIs based on reading IR are going to remain highly stable and that more
wrapper like APIs (IR creation, etc) are going to both be added and change
as the underlying IR changes.

----

Thoughts?

Thanks!

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/d2164bf5/attachment.html>

On Tue, Mar 1, 2016 at 2:39 PM, Eric Christopher <echristo at gmail.com>
wrote:
>>
>> - Eric: should the new C API Changes part of the developer policy be
>> pointed out? Maybe in relation to where we mention changes to the C
>> API?
>>
>
> Good point, how about this:
>
> ----
>
> We have documented our C API stability guarantees for both development and
> release branches, as well as documented how to extend the C API. Please see
> the developer documentation at
> http://llvm.org/docs/DeveloperPolicy.html#c-api-changes for more
> information.
>
> ----
Thanks! r262496.

> On Feb 26, 2016, at 9:16 AM, Hans Wennborg via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> If you were thinking about writing a note for 3.8 but didn't get
> around to it yet, this is the final reminder.
> 
> (In particular, the notes for X86 and PowerPC could use some attention.)
You asked for a release note about alignment; here you go.

 --

Alignment

Clang has gotten better at passing down strict type alignment information to
LLVM,
and several targets have gotten better at taking advantage of that information.

Dereferencing a pointer that is not adequately aligned for its type is undefined
behavior.  It may crash on target architectures that strictly enforce alignment,
but
even on architectures that do not, frequent use of unaligned pointers may hurt
the performance of the generated code.

If you find yourself fixing a bug involving an inadequately aligned pointer, you
have several options.

The best option, when practical, is to increase the alignment of the memory.
For example, this array is not guaranteed to be sufficiently aligned to store
a pointer value:

  char buffer[sizeof(const char*)];

Writing a pointer directly into it violates C's alignment rules:

  ((const char**) buffer)[0] = “Hello, world!\n”;

But you can use alignment attributes to increase the required alignment:

  __attribute__((aligned(__alignof__(const char*))))
  char buffer[sizeof(const char*)];

When that’s not practical, you can instead reduce the alignment requirements
of the pointer.  If the pointer is to a struct that represents that layout of a
serialized structure, consider making that struct packed; this will remove any
implicit internal padding that the compiler might add to the struct and
reduce its alignment requirement to 1.

  struct file_header {
    uint16_t magic_number;
    uint16_t format_version;
    uint16_t num_entries;
  } __attribute__((packed));

You may also override the default alignment assumptions of a pointer by
using a typedef with explicit alignment:

  typedef const char *unaligned_char_ptr __attribute__((aligned(1)));
  ((unaligned_char_ptr*) buffer)[0] = “Hello, world!\n”;

The final option is to copy the memory into something that is properly
aligned.  Be aware, however, that Clang will assume that pointers are
properly aligned for their type when you pass them to a library function
like memcpy.  For example, this code will assume that the source and
destination pointers are both properly aligned for an int:

  void copy_int_array(int *dest, const int *src, size_t num) {
    memcpy(dest, src, num * sizeof(int));
  }

You may explicitly disable this assumption by casting the argument to a
less-aligned pointer type:

  void copy_unaligned_int_array(int *dest, const int *src, size_t num) {
    memcpy((char*) dest, (const char*) src, num * sizeof(int));
  }

Clang promises not to look through the explicit cast when inferring the
alignment of this memcpy.

 --

John.