Announcement

Collapse
No announcement yet.

Local Register Allocator Merged Into GCC (LRA)

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

  • Local Register Allocator Merged Into GCC (LRA)

    Phoronix: Local Register Allocator Merged Into GCC (LRA)

    The LRA branch has been merged into GCC trunk as a new feature of GCC 4.8...

    http://www.phoronix.com/vr.php?view=MTIxMjI

  • #2
    where the eff is my wayland?

    Comment


    • #3
      Originally posted by garegin View Post
      where the eff is my wayland?
      It will take over the world tomorrow afternoon at 3 o'clock.

      Come on, people, you know it will take years.

      Comment


      • #4
        LRA is work in progress...

        There is not much to write about for LRA from user's perspective as generated code is 1-2% SLOWER, so we'll have to wait for 4.9 to see any real benefit...

        Comment


        • #5
          Originally posted by Brane215 View Post
          There is not much to write about for LRA from user's perspective as generated code is 1-2% SLOWER, so we'll have to wait for 4.9 to see any real benefit...
          did you rebuild your libraries with it? wouldn't you need your low-level hw access (like stdio.h) be astemic throughout? Not sure but if not, you may have redundancy in your functions.

          (my gentoo is down...)

          ~Jux

          Comment


          • #6
            No, I did not bother. it's totally peripheral feature for me. Whatever it is , it seems to be much more interesting for compiler developers than users.

            At least until it produces some real benefit that will be visible in the compiled code and worth the upgrade.

            Comment


            • #7
              Originally posted by Brane215 View Post
              No, I did not bother. it's totally peripheral feature for me. Whatever it is , it seems to be much more interesting for compiler developers than users.

              At least until it produces some real benefit that will be visible in the compiled code and worth the upgrade.
              Toolchains, those optimized functions will probably increase performance in file systems, compression, & parsers..horay.

              ~Jux

              Comment


              • #8
                so we'll have to wait for 4.9 to see any real benefit

                Comment


                • #9
                  I was thinking more like new distro release not compiler release. It's in there, mainline 4.8... you (or your distro maintainer) needs to cook it in and recompile (or start from scratch) tool-chains (binutls,bzip,e2fsprogs,etc), libraries & kernel. Then rebuild packages from source. Time consuming unless you have a quad mangy-courus w/ 1/4TB of RAM But its in the trunk as of 4.8....You should seen come benefit in your applications after your assemblers and parsers have those functions. Alabaster toilets of pristine convenience, marbled floor, amber gris sent of the most exotic origins, and silk to wipe with....after you pour the foundation,frame, and plum your masonry. lol, But seriously, this really does get rid of alot of low-level redundant hooks and streamlines. My haskell source is compiling and it's simply amazing. <JoKing>

                  ~/Jux

                  Comment


                  • #10
                    this is exactly what i need

                    it is when you make a loop with many variables and the compiler needs to assign registers to hold that values

                    if the compiler does a bad job or it cant possibly hold all the needed values, then comes register spilling
                    that is the value must be saved to RAM that is much slower then the cpu


                    this is good for tight loops with lots of calculations on lots of variables for example

                    Comment

                    Working...
                    X