llvm dev - Jan 2013 - [LLVMdev] Using C++'11 language features in LLVM itself

It's seems like a quiet and peaceful day, lets stir things up a bit :)

How crazy would it be for us to start using basic C++'11 language features
(but not C++'11 library features) in LLVM: things like auto, rvalue-refs,
lambdas, etc?  I think that we can keep things well defined with a few simple
requirements: language features must be supported by MSVC 2010 and later, some
version of GCC and later (linux folks should pick?), some version of Clang and
later (Freebsd folks?).

On the one hand, this would greatly clean up code and is definitely the path
forward.  On the other hand, I don't want to substantially harm adoption or
use of LLVM by adding another burden to building and developing it.

If doing this would be a big problem for you, please speak up, and explain
how/when the problem can be resolved.  We will certainly adopt C++'11
features someday, so even if it isn't soon, it is good to have the
discussion to find out what the issues are.

-Chris

On 01/08/2013 03:45 PM, Chris Lattner wrote:
> It's seems like a quiet and peaceful day, lets stir things up a bit :)
>
> How crazy would it be for us to start using basic C++'11 language
features (but not C++'11 library features) in LLVM: things like auto,
rvalue-refs, lambdas, etc?  I think that we can keep things well defined with a
few simple requirements: language features must be supported by MSVC 2010 and
later, some version of GCC and later (linux folks should pick?), some version of
Clang and later (Freebsd folks?).
>
> On the one hand, this would greatly clean up code and is definitely the
path forward.  On the other hand, I don't want to substantially harm
adoption or use of LLVM by adding another burden to building and developing it.
>
> If doing this would be a big problem for you, please speak up, and explain
how/when the problem can be resolved.  We will certainly adopt C++'11
features someday, so even if it isn't soon, it is good to have the
discussion to find out what the issues are.
>
> -Chris
>
How about being able to use RTTI and exceptions? (stir, stir...)

Reed

On Tue, Jan 8, 2013 at 3:54 PM, Reed Kotler <rkotler at mips.com>
wrote:
> On 01/08/2013 03:45 PM, Chris Lattner wrote:
>>
>> It's seems like a quiet and peaceful day, lets stir things up a bit
:)
>>
>> How crazy would it be for us to start using basic C++'11 language
features
>> (but not C++'11 library features) in LLVM: things like auto,
rvalue-refs,
>> lambdas, etc?  I think that we can keep things well defined with a few
>> simple requirements: language features must be supported by MSVC 2010
and
>> later, some version of GCC and later (linux folks should pick?), some
>> version of Clang and later (Freebsd folks?).
>>
>> On the one hand, this would greatly clean up code and is definitely the
>> path forward.  On the other hand, I don't want to substantially
harm
>> adoption or use of LLVM by adding another burden to building and
developing
>> it.
>>
>> If doing this would be a big problem for you, please speak up, and
explain
>> how/when the problem can be resolved.  We will certainly adopt
C++'11
>> features someday, so even if it isn't soon, it is good to have the
>> discussion to find out what the issues are.
>>
>> -Chris
>>
> How about being able to use RTTI and exceptions? (stir, stir...)
Please don't discuss RTTI/exceptions in this thread.  All the
compilers which can compile LLVM already support both RTTI and
exceptions to a usable level; we don't use them for other reasons.

-Eli

Reed Kotler <rkotler at mips.com> writes:
> How about being able to use RTTI and exceptions? (stir, stir...)
+1.  RAII is super important.

                                  -David

On Tue, Jan 8, 2013 at 6:45 PM, Chris Lattner <clattner at apple.com>
wrote:
> some version of GCC and later (linux folks should pick?)
4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which
is the latest Long Term Support release (which come out every 2 years,
with 3 years desktop support and 5 years server support), so I
wouldn't push farther than that on Linux for the time being.



Another thing to bring up is that we have a lot of classes which have
method pairs `foo_begin()` and `foo_end()` (e.g.
`Function::arg_{begin,end}()`). These don't play nice with range-for
loops (we are already seeing this come up in LLD). We probably should
adopt some lightweight "range" class and a naming convention
(`foo_all()`?) that will interact well with range-for. jyasskin, you
have some standards proposals for such a class, maybe you could try
bringing that into tree?

-- Sean Silva

Chris Lattner <clattner at apple.com> writes:
> It's seems like a quiet and peaceful day, lets stir things up a bit :)
>
> How crazy would it be for us to start using basic C++'11 language
> features (but not C++'11 library features) in LLVM: things like auto,
> rvalue-refs, lambdas, etc?  I think that we can keep things well
> defined with a few simple requirements: language features must be
> supported by MSVC 2010 and later, some version of GCC and later (linux
> folks should pick?), some version of Clang and later (Freebsd folks?).
Note that this is NOT an official message from Cray in any way, shape or
form.  I've passed on your note to our group for information but I don't
expect a serious problem with this given enough lead time.

I am personally very much in favor of this.  C++11 really is a huge leap
from C++03 in terms of readability, maintainability and safety.

Why not C++11 libraries?  Implementation/capatability reasons?  I don't
know anything about how the various implementation compare in terms of
completeness.  But the libraries use the new language features and
theoretically you get a performance boost "for free."

I'm assuming we wouldn't release an llvm with C++11 until 3.4 at least
which gives folks a good 8 months to a year to prepare.  Doing it in a
3.3 release shortens that considerably but it might be ok.  The biggest
issue for groups like ours is upgrading the compiler we use to build our
compiler.  We have a LOT of components and they all have to work with
the new build environment.  It involves a lot of testing and assurance
which is where we might bump up against a 3.3 release, not having a new
compiler in place before 3.3 is out.

As for gcc version, it looks like 4.7.2 is in Debian Wheezy and that's
usually the most common distribution to lag behind in these kinds of
things.  I think that's sufficiently new for Linux but someone correct
me if that's wrong.

                              -David

On Tue, Jan 8, 2013 at 4:17 PM, Sean Silva <silvas at purdue.edu>
wrote:
> On Tue, Jan 8, 2013 at 6:45 PM, Chris Lattner <clattner at apple.com>
wrote:
>> some version of GCC and later (linux folks should pick?)
>
> 4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which
> is the latest Long Term Support release (which come out every 2 years,
> with 3 years desktop support and 5 years server support), so I
> wouldn't push farther than that on Linux for the time being.
>
>
>
> Another thing to bring up is that we have a lot of classes which have
> method pairs `foo_begin()` and `foo_end()` (e.g.
> `Function::arg_{begin,end}()`). These don't play nice with range-for
> loops (we are already seeing this come up in LLD). We probably should
> adopt some lightweight "range" class and a naming convention
> (`foo_all()`?) that will interact well with range-for. jyasskin, you
> have some standards proposals for such a class, maybe you could try
> bringing that into tree?
The C++ proposal changes rapidly. While it would be great to get usage
experience from LLVM in order to inform the C++ proposal, I don't have
"what will eventually be in C++" to propose for LLVM. Well, I'd
expect
some "range<IteratorType>" template with .begin() and .end()
methods,
but I don't even know what name that template will have.

I'm not sure this part of the discussion is on-topic for Chris's
thread, since it's not related to a potential problem with enabling
C++ language features. (Not having a range type doesn't make
range-based for loops fail to compile on some platform, it just makes
them slightly less useful.)

Jeffrey

Sean Silva <silvas at purdue.edu> writes:
> On Tue, Jan 8, 2013 at 6:45 PM, Chris Lattner <clattner at apple.com>
wrote:
>> some version of GCC and later (linux folks should pick?)
>
> 4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which
> is the latest Long Term Support release (which come out every 2 years,
> with 3 years desktop support and 5 years server support), so I
> wouldn't push farther than that on Linux for the time being.
Does 4.6 work sufficiently for C++11?  I haven't used it in quite a
while.
> Another thing to bring up is that we have a lot of classes which have
> method pairs `foo_begin()` and `foo_end()` (e.g.
> `Function::arg_{begin,end}()`). These don't play nice with range-for
> loops (we are already seeing this come up in LLD). We probably should
> adopt some lightweight "range" class and a naming convention
> (`foo_all()`?) that will interact well with range-for. jyasskin, you
> have some standards proposals for such a class, maybe you could try
> bringing that into tree?
+1.  I've done this in my own code and it is so very nice.  :)

                             -David

On Tue, Jan 08, 2013 at 03:45:52PM -0800, Chris Lattner
wrote:
> How crazy would it be for us to start using basic C++'11 language
> features (but not C++'11 library features) in LLVM: things like auto,
> rvalue-refs, lambdas, etc?  I think that we can keep things well
> defined with a few simple requirements: language features must be
> supported by MSVC 2010 and later, some version of GCC and later (linux
> folks should pick?), some version of Clang and later (Freebsd folks?).
>From a NetBSD perspective, the real big issue is bootstrapping the
compiler. Natively, that would mean supporting GCC 4.1 and 4.5,
disabling optimisation is acceptable. FreeBSD likely wants to add GCC
4.2 to that last.

Joerg

On 1/8/2013 5:45 PM, Chris Lattner wrote:
>
>some version of Clang and later (Freebsd folks?).
FreeBSD 9.1 uses GCC 4.2.1 and Clang 3.0, although I have some doubts 
about the clang, at least on PPC32.  Trunk clang compiled with the 
system clang crashes on code that the same trunk clang compiles fine 
when built with gcc.  It may as well be a source problem in trunk though...

-Krzysztof


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

Seeing as I'm using OS X and Debian Sid which is on GCC 4.7.2-5 which 
moved over to Wheezy for Debian 7 release it seems more reasonable to 
target that than using Ubuntu's 4.6.x which is never more conservative 
than Debian on releases.

- Marc

P.S. I'm more interested in actually seeing if this will improve an 
actual smooth installation of libc++ with llvm/clang/compiler-rt trunk 
so I can actually start using libc++ on Linux and not have to hack 
around to get it working. Get that going and I'm sure with Debian's dual
FreeBSD/Linux building of Deb packages with LLVM/Clang you'll get plenty 
of community testing.


On 01/08/2013 04:24 PM, dag at cray.com wrote:
> Chris Lattner <clattner at apple.com> writes:
>
>> It's seems like a quiet and peaceful day, lets stir things up a bit
:)
>>
>> How crazy would it be for us to start using basic C++'11 language
>> features (but not C++'11 library features) in LLVM: things like
auto,
>> rvalue-refs, lambdas, etc?  I think that we can keep things well
>> defined with a few simple requirements: language features must be
>> supported by MSVC 2010 and later, some version of GCC and later (linux
>> folks should pick?), some version of Clang and later (Freebsd folks?).
> Note that this is NOT an official message from Cray in any way, shape or
> form.  I've passed on your note to our group for information but I
don't
> expect a serious problem with this given enough lead time.
>
> I am personally very much in favor of this.  C++11 really is a huge leap
> from C++03 in terms of readability, maintainability and safety.
>
> Why not C++11 libraries?  Implementation/capatability reasons?  I don't
> know anything about how the various implementation compare in terms of
> completeness.  But the libraries use the new language features and
> theoretically you get a performance boost "for free."
>
> I'm assuming we wouldn't release an llvm with C++11 until 3.4 at
least
> which gives folks a good 8 months to a year to prepare.  Doing it in a
> 3.3 release shortens that considerably but it might be ok.  The biggest
> issue for groups like ours is upgrading the compiler we use to build our
> compiler.  We have a LOT of components and they all have to work with
> the new build environment.  It involves a lot of testing and assurance
> which is where we might bump up against a 3.3 release, not having a new
> compiler in place before 3.3 is out.
>
> As for gcc version, it looks like 4.7.2 is in Debian Wheezy and that's
> usually the most common distribution to lag behind in these kinds of
> things.  I think that's sufficiently new for Linux but someone correct
> me if that's wrong.
>
>                                -David
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- 
Marc J. Driftmeyer
Email :: mjd at reanimality.com <mailto:mjd at reanimality.com>
Web :: http://www.reanimality.com
Cell :: (509) 435-5212
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/b727002e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjd.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/b727002e/attachment.vcf>

On Jan 8, 2013, at 4:24 PM, dag at cray.com wrote:
> I am personally very much in favor of this.  C++11 really is a huge leap
> from C++03 in terms of readability, maintainability and safety.
I agree completely.
> Why not C++11 libraries?  Implementation/capatability reasons?  I don't
> know anything about how the various implementation compare in terms of
> completeness.  But the libraries use the new language features and
> theoretically you get a performance boost "for free."
It's mostly about only changing one thing at a time.  It's already
possible to build LLVM in C++'11 mode and with a C++'11 library.  Adding
a dependency to *require* C++'11 compiler and/or C++'11 library are two
orthogonal changes, and I'd like to tackle them one at a time.
 
> I'm assuming we wouldn't release an llvm with C++11 until 3.4 at
least
> which gives folks a good 8 months to a year to prepare.  Doing it in a
> 3.3 release shortens that considerably but it might be ok.  The biggest
> issue for groups like ours is upgrading the compiler we use to build our
> compiler.  We have a LOT of components and they all have to work with
> the new build environment.  It involves a lot of testing and assurance
> which is where we might bump up against a 3.3 release, not having a new
> compiler in place before 3.3 is out.
> 
> As for gcc version, it looks like 4.7.2 is in Debian Wheezy and that's
> usually the most common distribution to lag behind in these kinds of
> things.  I think that's sufficiently new for Linux but someone correct
> me if that's wrong.
Wow, requiring GCC 4.7 would be really aggressive, it was just released in March
2012.  Call me conservative, but I was thinking that a reasonable GCC baseline
would be GCC 4.4 or something (which is ~3.5 years old).

-Chris

It's not a coincidence that GCC 4.2.1 is the baseline on FreeBSD 
considering the licensing of GPL restrictions on new releases.

- Marc

On 01/08/2013 04:46 PM, Krzysztof Parzyszek wrote:
> On 1/8/2013 5:45 PM, Chris Lattner wrote:
>>
>> some version of Clang and later (Freebsd folks?).
>
> FreeBSD 9.1 uses GCC 4.2.1 and Clang 3.0, although I have some doubts 
> about the clang, at least on PPC32.  Trunk clang compiled with the 
> system clang crashes on code that the same trunk clang compiles fine 
> when built with gcc.  It may as well be a source problem in trunk 
> though...
>
> -Krzysztof
>
>
-- 
Marc J. Driftmeyer
Email :: mjd at reanimality.com <mailto:mjd at reanimality.com>
Web :: http://www.reanimality.com
Cell :: (509) 435-5212
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/57f4631f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjd.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/57f4631f/attachment.vcf>

09.01.2013, 04:11, "Chris Lattner" <clattner at
apple.com>:
> It's seems like a quiet and peaceful day, lets stir things up a bit :)
>
> How crazy would it be for us to start using basic C++'11 language
features (but not C++'11 library features) in LLVM:
> things like auto
It can make code less readable because of missing types. When compiler can
deduce type, it doesn't always mean that human do it easily when reading the
code.
> rvalue-refs
It is not very helpful when compiler can do return value optimization.
> lambdas
May significantly degrade readability when used lightly.

What is the purpose of these changes then? Just to use brand new kinds of
syntactic sugar?

-- 
Regards,
Konstantin

> How crazy would it be for us to start using basic C++'11 language
features (but not C++'11 library features) in LLVM:
> things like auto
| It can make code less readable because of missing types. When compiler can
deduce type, it doesn't always mean that human do it easily when reading the
code.

I'd argue that auto should only be used in cases where the precise type
being used isn't something the human reader actually reads anyway. I've
ended up with the habit of not registering the,
say, std::vector<tree<bin_expr<float,true,true,false> >
>::iterator in

for(std::vector<tree<bin_expr<float,true,true,false> >
>::iterator it = worklist.begin(); it != worklist.end(); ++it)

In cases like this auto increases readability by decreasing the amount of
"pattern discarding" I have to do before spotting the things I'm
going to pay attention to. If the actual type is something that the reader is
going to think about, then IMO auto shouldn't be used as a coding style
issue.
> rvalue-refs
| It is not very helpful when compiler can do return value optimization.

I thought the motivation for adding rvalue-refs in C++11 was that in practice
compilers can almost never do enough analysis to do RVO on real-world code?

Regards,
Dave


-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.

On 1/10/2013 4:43 AM, Konstantin Tokarev wrote:
>
>> lambdas
>
> May significantly degrade readability when used lightly.
It may also improve readability, especially in cases where you would 
normally have to define your own class with operator(), or your own 
function.

-Krzysztof


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