[LLVMbugs] [Bug 18684] New: poor optimization of code that has a monotone i1 flag

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=18684

            Bug ID: 18684
           Summary: poor optimization of code that has a monotone i1 flag
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider:

#include <vector>                                                  
thread_local std::vector<int> v;
int main(){
  for(long i=0;i<400000000;++i){
    v.push_back(i);
  }
  return v.size();
}

Building this with -O3 generates a loop like this:

static thread_local bool __tls_guard = false;
int main() {
  long i = 0;

for_cond:
  bool need_init = !__tls_guard;
  __tls_guard = true;
  if (need_init) {
    construct v;
  }
  v.push_back(i);
  if (++i < 4000000000)
    goto for_cond;

  return v.size();
}

We should be able to hoist the initialization and construction of 'v' out of
the loop. In particular, we have an internal thread_local global, and the only
stores to it within the module store 'i1 1', so the value of the variable is
always 1 on the second and subsequent loop iterations.

Clang could emit an @llvm.invariant.start after the store to __tls_guard if
it'd be helpful, but that seems redundant in this case, since the variable is
internal and only ever has one value stored to it, and in any case, manually
adding that to the IR doesn't enable any further optimization currently.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140131/74876497/attachment.html>