Announcement

Collapse
No announcement yet.

LLVM / Clang 6.0 Should Be Released Soon With Its Many New Features

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • LLVM / Clang 6.0 Should Be Released Soon With Its Many New Features

    Phoronix: LLVM / Clang 6.0 Should Be Released Soon With Its Many New Features

    LLVM 6 is running a few days behind scheduled for its release along with Clang 6 for the C/C++ compiler, but this latest big update to this open-source compiler stack should still be on the ways in the days ahead...

    http://www.phoronix.com/scan.php?pag....0-Coming-Soon

  • #2
    Hammering F5 button :
    https://llvm.org/svn/llvm-project/ll...s/RELEASE_600/
    I'm having some regressions with llvm-svn + mesa-git, so I hope freshly compiled new final releases of both will do the trick.

    Comment


    • #3
      Originally posted by InsideJob View Post
      or virtual machines or sumptin' like that...
      Well, it was originally called Low Level Virtual Machine.

      Comment


      • #4
        Originally posted by FishPls View Post

        Well, it was originally called Low Level Virtual Machine.
        Frankly I thought it still meant that but checking thier website they state that it isn't an acronym anymore... I guess that is to deter somewhat people thinking that it would make a good basis for a other things like a JVM etc... which it can do technically but there are better options. It's actually more of a rethink on how to implement heavyweight compilers with a robust IR and reusability as a library.

        Comment


        • #5
          Congrats LLVM team with the new milestone. It is great to see the project becoming more feature rich.

          One feature that our project uses is 'scalar_storage_order' attribute from GCC. This attribute allows to avoid Net::bswap() functions calls everywhere and we instantly got addicted the feature since the first day we tried it.

          I just checked status of this feature in Clang https://bugs.llvm.org/show_bug.cgi?id=35293 and there no progress since LLVM 5 release. Too bad. I guess we are still going to stay with GCC.

          Comment


          • #6
            I really joy reading up on your benchmarks - they are very informative; however on many of your benchmarks there are no tests which incorporate '-O2' flags.

            There are a few school of thoughts on why O2 should be used instead of O3 namely O3 produces slower code.

            Maybe this would go some way to debunking this myth.

            Comment


            • #7
              Originally posted by armetuz View Post
              Congrats LLVM team with the new milestone. It is great to see the project becoming more feature rich.

              One feature that our project uses is 'scalar_storage_order' attribute from GCC. This attribute allows to avoid Net::bswap() functions calls everywhere and we instantly got addicted the feature since the first day we tried it...
              Wait. Do you mean you can set "#pragma scalar_storage_order big-endian" at the top of some global header file, and kiss ntohs() & friends goodbye?

              Comment


              • #8
                Originally posted by pipe13 View Post
                Wait. Do you mean you can set "#pragma scalar_storage_order big-endian" at the top of some global header file
                No, I use attribute that can be set at a struct. Something like this:

                Code:
                struct __attribute__((scalar_storage_order("big-endian"))) udp_hdr {
                    uint16_t src_port;
                    uint16_t dest_port;
                    uint16_t length;
                    uint16_t checksum;
                };
                It is super convenient. After I started using it, ntohs() feels like a dirty workaround.

                Comment


                • #9
                  Originally posted by armetuz View Post
                  Congrats LLVM team with the new milestone. It is great to see the project becoming more feature rich.

                  One feature that our project uses is 'scalar_storage_order' attribute from GCC. This attribute allows to avoid Net::bswap() functions calls everywhere and we instantly got addicted the feature since the first day we tried it.

                  I just checked status of this feature in Clang https://bugs.llvm.org/show_bug.cgi?id=35293 and there no progress since LLVM 5 release. Too bad. I guess we are still going to stay with GCC.
                  Convenient, but entirely non-standard. With C++ you can define byte-swapped (u)int types to archive the same (ie. casting an buint32 to uint32 will automatically byteswap).
                  If you want to stick with gcc fine, but if the slow C++ standardization has any advantage then its that standard code will be compatible with every compiler.

                  Btw. cant remember any LLVM release that wasnt atleast 2 weeks late, most been 1 month behind.

                  Comment


                  • #10
                    Originally posted by discordian View Post

                    With C++ you can define byte-swapped (u)int types to archive the same (ie. casting an buint32 to uint32 will automatically byteswap).
                    If you want to stick with gcc fine, but if the slow C++ standardization has any advantage then its that standard code will be compatible with every compiler.
                    Luckily I do not use C++. I need a language-independent solution and scalar_storage_order attribute works just great. GCC seems more innovative in implementing this kind of features, so yeah, we are going to use GCC. That's unfortunate as I prefer to be able to compile my project with both GCC and CLANG.
                    Last edited by armetuz; 02-27-2018, 05:29 PM.

                    Comment

                    Working...
                    X