[LLVMbugs] [Bug 19177] New: Implement support in clang-cl for the /GT option

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Mar 18 11:56:10 PDT 2014


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

            Bug ID: 19177
           Summary: Implement support in clang-cl for the /GT option
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: bigcheesegs at gmail.com, llvmbugs at cs.uiuc.edu,
                    rnk at google.com
    Classification: Unclassified

The option is defined in
http://msdn.microsoft.com/en-us/library/6e298fy4.aspx

In summary, it means that we cannot assume that the address of a tls doesn't
change across a call, since the call might causes a fiber to move to another
thread.

This has implications for both IR and codegen. For the IR issue, consider

struct foo {
  int v[10];
};
static __thread struct foo var;
struct foo *h(void) { return &var; }
void f(int *);
void g(int x, int y) {
  for (int i = 0; i < x; ++i) {
    f(&var.v[y]);
  }
}

This currently produces
------------------------------
for.body.lr.ph:
...
%arrayidx = getelementptr inbounds %struct.foo* @var, i64 0, i32 0, i64
%idxprom
br label %for.body

for.body:
...
tail call void @f(i32* %arrayidx)
...
br i1 %exitcond, label %for.end, label %for.body
----------------------------------

but the address is not actually loop invariant.

For codegen, consider

static __thread int var;
int *h(void) { return &var; }
void f(int);
void g(void) {
  f(var);
  f(var);
}

We only call __tls_get_addr at PLT once with the local dynamic model.

We chatted a bit about it and it looks like we would need to change clang's
IRGen when the option is given to use an intrinsic to get the actual address.
Something like

%addr = llvm.get_tls_addr(@var)

so that the optimizers know that %addr can be different in each loop iteration.

-- 
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/20140318/9419f95a/attachment.html>


More information about the llvm-bugs mailing list