Results 1 to 10 of 10

Thread: Local Register Allocator Merged Into GCC (LRA)

  1. #1
    Join Date
    Jan 2007
    Posts
    15,678

    Default 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. #2
    Join Date
    Nov 2011
    Posts
    353

    Default

    where the eff is my wayland?

  3. #3
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    Quote 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.

  4. #4
    Join Date
    Jul 2012
    Posts
    150

    Default 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...

  5. #5
    Join Date
    Feb 2010
    Posts
    28

    Default

    Quote 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

  6. #6
    Join Date
    Jul 2012
    Posts
    150

    Default

    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.

  7. #7
    Join Date
    Feb 2010
    Posts
    28

    Thumbs up

    Quote 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

  8. #8
    Join Date
    Oct 2012
    Posts
    6

    Default

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

  9. #9
    Join Date
    Feb 2010
    Posts
    28

    Default

    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

  10. #10
    Join Date
    May 2012
    Posts
    681

    Default

    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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •