This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Unlocked IO transformation - off by default
AbandonedPublic

Authored by xbolva00 on Jul 25 2018, 11:17 AM.

Details

Reviewers
vsk
Summary

+ option to enable it

Info about transformation: https://reviews.llvm.org/D45736

Diff Detail

Repository
rL LLVM

Event Timeline

xbolva00 created this revision.Jul 25 2018, 11:17 AM

Sadly, i'm not seeing much answers to the questions @vsk raised

I'd like to see a fuller justification here. Could you elaborate?

  • What does the typical improvement look like?
  • How common is this pattern is in the open source programs you looked at?
  • What do you think the policy should be for simplifying libcalls in a way

that can break interceptors?

Could you CC the reviewer, rja (Joe) on this thread? They may have some
insight. I can't find their email address. They appear to have stopped
commenting on Phab shortly after this commit landed.

xbolva00 added a comment.EditedJul 25 2018, 11:25 AM

I sent it under r332452 but anyway..

Typical case is

void log(data) {

 file = fopen(....)
 for (...) 
     fwrite(data ..)
... maybe some more logging ...
close(file);

} // cond: file does not escape

Here we replace e.g. fwrite (in this example) (which needs to lock and unlock internal lock to be thread safe) with fwrite_unlocked which does not do expensive lock/unlock.
I tried several small open source projects and I got several hits.

  • What does the typical improvement look like? Avoid useless locking in I/O functions, faster output to files.
  • What do you think the policy should be for simplifying libcalls in a way that can break interceptors?

-> off by default + option to enable. Maybe interceptors can be extended in the future to handle this transformation/function calls?

Any ideas for option name? Is this one ok?

xbolva00 abandoned this revision.Aug 10 2018, 6:05 AM