llvm dev - Feb 2016 - strace clang refers files from lib/tls/x86_64 multiple times

Greetings!

Sample program:
int main(int argc, char **argv)
{
    int myLocal=0xAA;
    return 0;
}

Command: clang t.c -o a.o -c

With above simple program we are observing that clang is stat-ing and trying to
open various files from lib/tls location. Eventually all calls to
"lib/tls" leads to ENOENT (No such file or directory)!

<sample_strace>
open("path/lib/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT     
(No such file or directory)
...
open("path/lib/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such   
file or directory)
...
</sample_strace>

The same behavior is not observed with GCC. With gcc we could build above sample
program under 30 seconds while it takes more than 100 seconds when using
clang!!!
Any pointer on how to reduce unnecessary stat/open is appreciated.

My local installation paths are...
                somepath/gcc-4.9.x/{bin,lib}
                somepath/llvm-3.7.1/{bin,lib}
                somepath/{bin,lib}

In above installation path we don't have "tls" directory.

In this regards I have following questions...
- We are not seeing present of "tls" directory under
"somepath/llvm-3.7.1/{bin,lib}" - is anything missing in our
installation?
- Why clang refers to "lib/tls"?
- Why clang refers to "lib/x86_64" ? And why not just using
"lib/"

Thank you in advance for your help.

Regards,
-Hiral

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/1a1bfd66/attachment.html>

Are you saying that these "find something in a directory that doesn't
exist" steps are taking a majority of the difference between 30 and 100
seconds? That does seem very unlikely to me, as `stat` in Linux/Unix is a
fairly well optimised function, and a lot of caching is done to ensure that
it doesn't take much time.

I'm not sure what the difference is, and nor what project you are working
on, but I doubt the searching through various paths for shared libraries is
the big problem.

--
Mats

On 8 February 2016 at 10:41, Oza, Hiral via cfe-dev <cfe-dev at
lists.llvm.org>
wrote:
> Greetings!
>
>
>
> Sample program:
>
> int main(int argc, char **argv)
>
> {
>
>     int myLocal=0xAA;
>
>     return 0;
>
> }
>
>
>
> Command: clang t.c –o a.o –c
>
>
>
> With above simple program we are observing that clang is stat-ing and
> trying to open various files from lib/tls location. Eventually all calls to
> “lib/tls” leads to ENOENT (No such file or directory)!
>
>
>
> <sample_strace>
>
> open("path/lib/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT
> (No such file or directory)
>
> …
>
> open("path/lib/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No
such
> file or directory)
>
> …
>
> </sample_strace>
>
>
>
> The same behavior is not observed with GCC. With gcc we could build above
> sample program under 30 seconds while it takes more than 100 seconds when
> using clang!!!
>
> Any pointer on how to reduce unnecessary stat/open is appreciated.
>
>
>
> My local installation paths are…
>
>                 somepath/gcc-4.9.x/{bin,lib}
>
>                 somepath/llvm-3.7.1/{bin,lib}
>
>                 somepath/{bin,lib}
>
>
>
> In above installation path we don’t have “tls” directory.
>
>
>
> In this regards I have following questions…
>
> - We are not seeing present of “tls” directory under
> “somepath/llvm-3.7.1/{bin,lib}” – is anything missing in our installation?
>
> - Why clang refers to “lib/tls”?
>
> - Why clang refers to “lib/x86_64” ? And why not just using “lib/”
>
>
>
> Thank you in advance for your help.
>
>
>
> Regards,
>
> -Hiral
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/f84c8288/attachment.html>

Hi,

On Mon, Feb 8, 2016 at 12:41 PM, Oza, Hiral via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Greetings!
>
>
>
> Sample program:
>
> int main(int argc, char **argv)
>
> {
>
>     int myLocal=0xAA;
>
>     return 0;
>
> }
>
>
>
> Command: clang t.c –o a.o –c
>
>
>
> With above simple program we are observing that clang is stat-ing and
trying
> to open various files from lib/tls location. Eventually all calls to
> “lib/tls” leads to ENOENT (No such file or directory)!
This is due to the way glibc searches for libraries, this is not a
clang related thing.

ismail

Are you sure your situation isn't similar to this:

$ which gcc
/usr/lib64/ccache/gcc
$ which clang
/usr/local/bin/clang

In other words, your `gcc` uses `ccache`, but `clang` doesn't?

That can indeed make a BIG difference in compile-time.

--
Mats


On 8 February 2016 at 12:27, Ismail Donmez via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> On Mon, Feb 8, 2016 at 12:41 PM, Oza, Hiral via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > Greetings!
> >
> >
> >
> > Sample program:
> >
> > int main(int argc, char **argv)
> >
> > {
> >
> >     int myLocal=0xAA;
> >
> >     return 0;
> >
> > }
> >
> >
> >
> > Command: clang t.c –o a.o –c
> >
> >
> >
> > With above simple program we are observing that clang is stat-ing and
> trying
> > to open various files from lib/tls location. Eventually all calls to
> > “lib/tls” leads to ENOENT (No such file or directory)!
>
> This is due to the way glibc searches for libraries, this is not a
> clang related thing.
>
> ismail
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/8b9f5a1d/attachment.html>