search for: 0at5ejfccbf

...t stats of the fast vs local vs linear scan at O0 on "opt -std-compile-opts" processed bitcode files. The fast regalloc is still certainly faster at codegen than local with such bitcode files. Let me know if the link doesn't work: https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en Misc stuff: I ran into an "UNREACHABLE executed" using linear scan on revision 104021, so I used an older version for that. 0 llc.hg 0x0000000000af4d7f 1 llc.hg 0x0000000000af54fa 2 libpthread.so.0 0x00007fb1734b67d0 3 lib...

...the fast vs local vs linear scan at O0 on "opt -std-compile-opts" processed bitcode files. The fast regalloc is still certainly faster at codegen than local with such bitcode files. Let me know if the link doesn't work: > > https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en Sorry, can't read that. > Misc stuff: I ran into an "UNREACHABLE executed" using linear scan on revision 104021, so I used an older version for that. Please use bugpoint to reduce the test case and then submit a PR. bugpoint -run-llc 4...

On May 17, 2010, at 9:09 PM, Rafael Espindola wrote: >> The fast and local register allocators are meant to be used on unoptimized code, a 'Debug build'. While they do work on optimized code, they do not give good results. Their primary goal is compile time, not code quality. > > Yes, we have a somewhat uncommon use case. It is fine to spend time > optimizing bitcode (LTO

> The fast and local register allocators are meant to be used on unoptimized code, a 'Debug build'. While they do work on optimized code, they do not give good results. Their primary goal is compile time, not code quality. Yes, we have a somewhat uncommon use case. It is fine to spend time optimizing bitcode (LTO is a OK), but we want to make the final IL -> Executable translation