- User Since
- Dec 15 2015, 10:55 AM (175 w, 22 h)
Mon, Apr 22
Thu, Apr 18
Does this look good now?
Mon, Apr 15
Thu, Apr 11
without second constructor
Wed, Apr 10
Tue, Apr 9
Updated as suggested by @rsmith (thanks!)
Thu, Apr 4
Tue, Apr 2
Feb 19 2019
Feb 14 2019
Feb 8 2019
Use [=] instead of explicitly passing StringRefs to ReportBufferError.
(Following the same archive(member) format also used by toString() in InputFiles.cpp)
lld-link: error: could not get the buffer for the member defining symbol spvDiagnosticDestroy: No such file or directory
Feb 7 2019
See earlier comment.
Feb 6 2019
Jan 30 2019
Jan 29 2019
LGTM, with some suggestions in the comments.
Jan 24 2019
Re-upload only the test change.
pcc, does D57192 implement your suggestion?
Just saw your comment, pcc. I'll look into that.
Jan 23 2019
add missing .1
replaced .c test with an .ll test
Jan 22 2019
Jan 4 2019
Sep 14 2018
Thanks! For the case where you don't want the files to expire, can you instead set the expiration age to 0? That should stop the pruner from removing them.
Sep 6 2018
I was thinking that as well, and it did fix the size regression: from 151,548,928 to 141,140,992 bytes, where the non-LTO version is 140,072,960 bytes.
Since r338767, "foo,p" and "bar,p" show up as "foo,px" and "bar,px", indicating that they are used in regular objects. However, there are no regular (non-LTO) objects in the test. Only main should have the 'x'.
Building Chromium with ThinLTO without this patch causes test_chrome_with_chromedriver.py to fail. With the patch, it runs successfully. (https://crbug.com/881036).
Aug 24 2018
We don't need this. Abandoning.
Aug 23 2018
This is really useful. Thanks for doing this. I got a couple of questions and comments in-line.
Aug 21 2018
update llvm/test/ThinLTO/X86/cache.ll to match the new expectations
Aug 20 2018
Do you know why the temporary files are being left on disk? I wouldn't have expected that to happen because they are being created with delete-on-close.
Aug 16 2018
Aug 2 2018
Comment changed in rL338755.
Sorry, Peter. Saw your reply after I had already pushed the change. Would:
Is this good to go?
Aug 1 2018
Use 36-character set instead of 32-character set, per @zturner's suggestion.
Yeah. On top of the cost of getting a number from the cryptographically secure random number generator, I don't think using mod instead of and will cost that much. I'll make the change. We could add a few more characters ("-_@", probably others), but I think digits+letters is already a good improvement to what we currently have, without having to worry about file systems not liking some characters.
Jul 31 2018
This diff fixes a problem where, on Windows, TempFile::create() would immediately fail when the same name is tried again before the first file with that name is gone. That makes collisions less of an issue, because we can actually use more of the available names before we give up. It also fixes a problem where trying to create a tempfile when all available names are taken would lead to an infinite loop.
@zturner, the models we use here are 6 characters. Chosen from a set of 16 characters gives 16M possibilities. Randomly generating them gives a 50%+ probability of a collision after 5000 names or so. I have another patch up (D50127) to use a 32-character set instead, which means the same 6 character model gives about a billion possible names and you need to generate about 40,000 of them before you have a 50% probability of a collision.
The inspiration for this is http://crbug.com/856635, where we're seeing the same file name generated multiple times during a single run.
Jul 26 2018
put error message check back in
Hmm, seems like I lost checking the error message along the way.
Per @pcc's suggestions:
Jul 25 2018
check for error message in test
Ah, just saw your comment about adding a check. Yes, I was checking that llvm-dis succeeds; I'll check for the error message instead to make it clearer what we're testing.
Thanks, @tejohnson! I made the test case smaller.