Can CODE_FOR_$(div$V$I$a3$) ever match?
This is genopinit.c:92 (sdivv_optab) (in revision 127595). I read this as "the next mode must be a full integer mode; add a v if it is a float mode". Which is doubly strange as this is the only place where $V is used. Am I missing something here, or is this a bug?
Last argument of lang_hooks_for_callgraph.analzye_tree unused?
Jan, I'm converting the call graph builder code for tuples and in the process I ran into calls to lang_hooks.callgraph.analyze_expr(). From what I've seen: 1- The third argument to that function (DECL), is not used by any callback. 2- In fact, if it was used, we'd ICE because the function signature expects a tree and we are calling it with a callgraph node. I'm tempted to just delete the argument. Unless you have a future use for it? Thanks.
Re: GCC 4.3 release schedule
On Mon, 29 Oct 2007, Jason Merrill wrote: > I think I prefer Richard's suggestion of not branching until we're ready to > make the .0 release. The effect should be the same except that people don't > have to deal with checking patches in on the branch vs. the trunk until after > 4.3.0 goes out. I like this approach. Gerald
Re: GCC 4.3 release schedule
Gerald Pfeifer wrote: On Mon, 29 Oct 2007, Jason Merrill wrote: I think I prefer Richard's suggestion of not branching until we're ready to make the .0 release. The effect should be the same except that people don't have to deal with checking patches in on the branch vs. the trunk until after 4.3.0 goes out. I like this approach. So have we come to some sort of consensus here? We leave mainline as stage 3 until we release? or at least have a somewhat final release candidate? Once we hit the target of 100 open PRs,( or whenever we would have originally cut a stage 3 release branch), we firm up stage 3 so that *really* only bugfixes go in. Then we work toward a release candidate, etc etc.? We can play it by ear, but do you want to wait to open stage 1 until we actually release 4.3, or do it after RC2 or something like that where there isn't much else going to happen to it? Either works for me, but I don't see that opening stage 1 before we actually release buys us much. Andrew
Re: GCC 4.3 release schedule
> >> I think I prefer Richard's suggestion of not branching until we're > >> ready to make the .0 release. The effect should be the same > >> except that people don't have to deal with checking patches in on > >> the branch vs. the trunk until after 4.3.0 goes out. > >> > > > > I like this approach. Me too. I'm also very pleased that the RM and SC are open and willing to consider changes of this nature to GCC release procedure. Thanks. > So have we come to some sort of consensus here? We leave mainline as > stage 3 until we release? or at least have a somewhat final release > candidate? The summary of this thread is that opening stage 1 before we release hurts us. So, we're trying to figure out another way. I think there is consensus that this is a good idea. Well, maybe not consensus, but all the posted commentary seems in favor. I assume if people objected, they'd say something... > Once we hit the target of 100 open PRs,( or whenever we would have > originally cut a stage 3 release branch), we firm up stage 3 so that > *really* only bugfixes go in. Then we work toward a release > candidate, etc etc.? I guess. This is the part that is less certain to me. There is less consensus here, in that Richard and I are advocating a strict time-based release schedule once the < 100 PR bit is flipped, with staggered RCs. (Richard, I hope this generalized summary is accurate.) Jason and Mark seem to be less impressed with this specific part. > We can play it by ear, but do you want to wait to open stage 1 until > we actually release 4.3, or do it after RC2 or something like that > where there isn't much else going to happen to it? Either works for > me, but I don't see that opening stage 1 before we actually release > buys us much. So, I'd guess Stage 1 opens after 4.3.0 is released, or at least tagged in SVN. -benjamin
Re: GCC 4.3 release schedule
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > Now that GCC is in stage 4.3, I think we'd all be in agreement that it > would be nice to keep this stage short and get a release out. Let me suggest something which is going sound a little crazy. Create a beta that is released now and then release one once (or twice) a month until we release 4.3. This is seperate from a release candidate and the snapshot. The beta is get attention from some folks that would not have used the snapshot before. It might get say some Fortran developers or some interesting C++ developers using it. We can write a little thing up on why we are doing the beta, C++0x support, more fortran support and vectorizer turned on by default at -O3. -- Pinski
Re: Last argument of lang_hooks_for_callgraph.analzye_tree unused?
> Jan, I'm converting the call graph builder code for tuples and in the > process I ran into calls to lang_hooks.callgraph.analyze_expr(). From > what I've seen: > > 1- The third argument to that function (DECL), is not used by any callback. > > 2- In fact, if it was used, we'd ICE because the function signature expects >a tree and we are calling it with a callgraph node. > > I'm tempted to just delete the argument. Unless you have a future use for it? Just go ahead and kill it. I would preffer to remove the whole hook, but we still keep some non-GIMPLE expressions in static initializers :( Honza > > > Thanks.
undocumented optimization options
Several options reported by --help=optimize are not documented in the GCC Manual (via invoke.texi) but are still reported with --help=optimize,^undocumented. Here are the options along with the people who checked in the entries to common.opt: -fipa-cp steven -fipa-matrix-reorg razya -fipa-pure-const zadeck (enabled with -O) -fipa-referencezadeck (enabled with -O) -fipa-type-escape zadeck -fvar-tracking-uninit ctice Is there a policy about whether an experimental option can be left undocumented, or should it be documented with a statement that it is experimental? If an option is left undocumented on purpose then its entry in common.opt should include "Undocumented". Janis
Re: GCC 4.3 release schedule
Andrew Pinski wrote: On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: Now that GCC is in stage 4.3, I think we'd all be in agreement that it would be nice to keep this stage short and get a release out. Let me suggest something which is going sound a little crazy. Create a beta that is released now and then release one once (or twice) a month until we release 4.3. This is seperate from a release candidate and the snapshot. The beta is get attention from some folks that would not have used the snapshot before. It might get say some Fortran developers or some interesting C++ developers using it. We can write a little thing up on why we are doing the beta, C++0x support, more fortran support and vectorizer turned on by default at -O3. Im not sure what that buys us. All the critical users are involved in creating the RC's. If we want others to use it, let them use the first RC and call it beta 1 instead/as well. I think most casual users will do the same thing I do for a linux distro, simply wait for the release so you are less likely to have to deal with instabilities. Andrew
Re: GCC 4.3 release schedule
On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote: > Create a beta that is released now and then release one once (or > twice) a month until we release 4.3. This is seperate from a release > candidate and the snapshot. The beta is get attention from some folks > that would not have used the snapshot before. It might get say some > Fortran developers or some interesting C++ developers using it. We > can write a little thing up on why we are doing the beta, C++0x > support, more fortran support and vectorizer turned on by default at > -O3. I would like this. It's common for snapshots to fail to build (at least on my machines), which is definitely a discouragement from trying them too often, and by the time the RCs hit it's way too late to do much about any problems but file a bug and hope it gets fixed in the next release. -Jack
Re: GCC 4.3 release schedule
On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote: > I would like this. It's common for snapshots to fail to build (at > least on my machines), which is definitely a discouragement from > trying them too often, and by the time the RCs hit it's way too late > to do much about any problems but file a bug and hope it gets fixed in > the next release. Perhaps we should make a prerelease now and call it a Technology Preview then... :-) -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.3 release schedule
On 11/1/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > > Once we hit the target of 100 open PRs,( or whenever we would have > > originally cut a stage 3 release branch), we firm up stage 3 so that > > *really* only bugfixes go in. Then we work toward a release > > candidate, etc etc.? > > I guess. This is the part that is less certain to me. There is less > consensus here, in that Richard and I are advocating a strict > time-based release schedule once the < 100 PR bit is flipped, with > staggered RCs. (Richard, I hope this generalized summary is accurate.) No, I was suggesting a more "when we think it's ready" approach (so, leave it basically unspecified). Of course we have the usual indicators of the number of regressions against previous releases and the number of P1 bugs. I don't think there should be any automatism at the point we reach <100 regressions. Rather for example once that happens, going over the remaining regressions and deciding which ones we want to fix before the release and doing so. Of course at some point a RC is warranted, as only that might be tested by some more obscure targets. > Jason and Mark seem to be less impressed with this specific part. I'd agree with them. Richard.
Re: GCC 4.3 release schedule
On 11/1/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote: > > I would like this. It's common for snapshots to fail to build (at > > least on my machines), which is definitely a discouragement from > > trying them too often, and by the time the RCs hit it's way too late > > to do much about any problems but file a bug and hope it gets fixed in > > the next release. > > Perhaps we should make a prerelease now and call it a Technology > Preview then... :-) Well, there are installable gcc 4.3 builds for openSUSE available, and I know of at least Debian packages in experimental. I wouldn't be surprised if Fedora also has gcc 4.3 packages ready. So Technology Previews are out there ;) Richard.
New FAILures on MIPS: g++.dg/tree-ssa/ivopts-1.C and gcc.dg/tree-ssa/pr33723.c...
The mipsel-linux target had been clean for C and C++ (except for mayalias-[23].c) at r129657: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01332.html g++.dg/tree-ssa/ivopts-1.C started failing by r129727: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01385.html And gcc.dg/tree-ssa/pr33723.c by r129776: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01439.html It appears that these are probably missed optimizations, but it would be nice to understand why they are failing on MIPS and not on say x86_64: http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00031.html David Daney
Re: GCC 4.3 release schedule
Jack Lloyd wrote: On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote: Create a beta that is released now and then release one once (or twice) a month until we release 4.3. This is seperate from a release candidate and the snapshot. The beta is get attention from some folks that would not have used the snapshot before. It might get say some Fortran developers or some interesting C++ developers using it. We can write a little thing up on why we are doing the beta, C++0x support, more fortran support and vectorizer turned on by default at -O3. I would like this. It's common for snapshots to fail to build (at least on my machines), which is definitely a discouragement from trying them too often, and by the time the RCs hit it's way too late to do much about any problems but file a bug and hope it gets fixed in the next release. I'd suggest we are close to a beta state right now, so if it fails to build there ought to be a high priority PR opened. Andrew
Re: GCC 4.3 release schedule
On Thu, 1 Nov 2007, Richard Guenther wrote: > Well, there are installable gcc 4.3 builds for openSUSE available, > and I know of at least Debian packages in experimental. I wouldn't > be surprised if Fedora also has gcc 4.3 packages ready. FreeBSD also has packages (and of course the source ports) available. ;-) Gerald
Re: New FAILures on MIPS: g++.dg/tree-ssa/ivopts-1.C and gcc.dg/tree-ssa/pr33723.c...
Hello! g++.dg/tree-ssa/ivopts-1.C started failing by r129727: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01385.html This one was introduced by adjusting the scan for the correct string. x86_64 doesn't fail because the test is XFAILed for this target. Otherwise, this is PR 26726. Uros.
What means the fat .gch file?
$ du -s /opt/gcc4*/include/c++/4.*/i686-pc-linux-gnu/bits/ 33793 /opt/gcc41320071029/include/c++/4.1.3/i686-pc-linux-gnu/bits/ 64743 /opt/gcc42320071031/include/c++/4.2.3/i686-pc-linux-gnu/bits/ 181 /opt/gcc43020071026/include/c++/4.3.0/i686-pc-linux-gnu/bits/ In /opt/gcc4*/include/c++/4.*/i686-pc-linux-gnu/bits/ there are * 33.65 MB of stdc++.h.gch/ from gcc-4.1-20071029 * 32.38 MB of stdc++.h.gch/ from gcc-4.2-20071031 * 32.20 MB of stdtr1c++.h.gch/ from gcc-4.2-20071031 *0 MB of no such dir. stdc++.h.gch/ from gcc-4.3-20071026 O0g.gch and O2g.gch from these dirs eat many MBs of disk space. Why? What is there inside of fat .gch file? What means the .gch file? J.C. Pizarro
Re: What means the fat .gch file?
On Thu, 1 Nov 2007, J.C. Pizarro wrote: > What is there inside of fat .gch file? What means the .gch file? This is a question for the gcc-help list, not gcc. The latter is for the development *of* GCC, not the development *with* GCC. You can easily find the answer to your question by Googling for "GCC .gch". I just did that, and the first hit already answers your question. Or you can read our info documentation, for example by running "info gcc" and search (by - for example) for ".gch" there. Again, this is not a question suitable for the gcc list itself. Gerald
Re: GCC 4.3 release schedule
On 11/1/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Mon, 29 Oct 2007, Jason Merrill wrote: > > I think I prefer Richard's suggestion of not branching until we're ready to > > make the .0 release. The effect should be the same except that people don't > > have to deal with checking patches in on the branch vs. the trunk until > > after > > 4.3.0 goes out. > > I like this approach. Likewise. Diego.
Re: Any Ada changes for GCC 4.3?
On Thu, 25 Oct 2007, Britt Snodgrass wrote: > I've noticed that the GCC changes pages > (http://gcc.gnu.org/gcc-4.2/changes.html and > http://gcc.gnu.org/gcc-4.3/changes.html ) are not usually updated for > Ada and/or GNAT. It anyone designated as a maintainer for this? Yes, Geert, Robert, and Arnaud (Cc:ed) are listed as maintainers of the Ada frontend in GCC and regularily update the code and fix bugs, together with several colleagues of theirs. It would be good to have more documentation on the changes we get on the Ada front, and I hope one of our maintainers will find the time to do so. Gerald
Old UTF16 patch
Hi, does anybody know if this patch ever got merged into GCC, or if UTF-16 is currently supported? ftp://ftp.sap.com/pub/i18N/utf16/ugcc-3.2/README Tom, I saw you replied to this thread, so maybe you know about this: http://mail.nl.linux.org/linux-utf8/2001-07/msg00064.html I believe the patch was originally from Suse, if it hasn't been merged I'll do some more digging, and see if somebody from Oracle can integrate this. My understanding is that it hasn't been integrated yet. thanks elena
Re: Old UTF16 patch
I haven't followed any developments relating to TR19769 in WG14 after its publication in detail; has WG14 yet given an answer on what should be done with u'C' where C represents a single character that requires a surrogate pair to represent in UTF-16 (to name one noted place where the TR underspecifies things)? I don't think there's much worthwhile in those old patches. Start with the ISO TR text, produce testcases that cover everything there and the desired semantics for everything the TR leaves unspecified or underspecified, and only once the testcases are settled work out an implementation for the agreed semantics. A TR is not a standard, so for C this must be disabled in all strict conformance modes (note that it affects the rules for lexing and so changes the semantics of conforming programs); likewise for C++98. The C++0x draft includes the notation from TR19769, so the feature should be enabled by default in C++0x (and so far as the C TR is compatible with C++0x, both should be followed in both C and C++ when the feature is enabled). -- Joseph S. Myers [EMAIL PROTECTED]
Results of 7z-4.55 performance with current GCCs.
-- 1. Unpack p7zip_4.55_src_all.tar.bz2 2. Edit CPP/7zip/Bundles/Alone/makefile adding LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3 3. time make 4. strip --strip-all bin/7za ; ls -l bin/7za ; size bin/7za 5. time dd if=/dev/zero bs=4k count=8k | ./bin/7za a -t7z -m0=lzma -mx=9 \ -mfb=273 -md=48m -ms=on -si trash.7z ; ls -l *7z # User's time is used, machine is Ath64 3200+ 2.0 GHz x1, 64+64K L1, 512K L2. # Every compilers are compiled with this configure ../configure --prefix=/opt/gcc? --disable-shared \ --disable-threads --disable-checking --enable-__cxa_atexit \ --enable-languages=c,c++,fortran,objc --enable-bootstrap -- 1. gcc-3.4.6 -- 2. gcc-4.1.3-20071029 export PATH=/opt/gcc41320071029/bin:$PATH export LD_LIBRARY_PATH=/opt/gcc41320071029/lib -- 3. gcc-4.2.3-20071031 export PATH=/opt/gcc42320071031/bin:$PATH export LD_LIBRARY_PATH=/opt/gcc42320071031/lib -- 4. gcc-4.3.0-20071026 export PATH=/opt/gcc43020071026/bin:$PATH export LD_LIBRARY_PATH=/opt/gcc43020071026/lib -- LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3 1. 1m24s compile, 1184180 file, 1172634 text, 6124 data, 27168 bss, 0m17s run. 2. 1m30s compile, 1204640 file, 1188955 text, 4684 data, 29160 bss, 0m25s run. 3. 1m44s compile, 1208640 file, 1192995 text, 4688 data, 29128 bss, 0m22s run. 4. 1m45s compile, 1336068 file, 1319986 text, 4396 data, 29128 bss, 0m52s run. -- LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3 \ -funroll-all-loops -finline-functions 1. 1m46s compile, 1731956 file, 1720453 text, 6124 data, 27168 bss, 0m12s run. 2. 1m51s compile, 1762528 file, 1746859 text, 4684 data, 29160 bss, 0m15s run. 3. 2m06s compile, 1779040 file, 1763367 text, 4688 data, 29128 bss, 0m18s run. 4. 2m35s compile, 2287204 file, 2271122 text, 4396 data, 29128 bss, 0m17s run. -- LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 -msse3 \ -funroll-loops -finline-functions 1. 1m42s compile, 1628564 file, 1617041 text, 6124 data, 27168 bss, 0m12s run. 2. 1m47s compile, 1627328 file, 1611675 text, 4684 data, 29160 bss, 0m15s run. 3. 2m00s compile, 1595072 file, 1579407 text, 4688 data, 29128 bss, 0m18s run. 4. 2m26s compile, 2108964 file, 2092866 text, 4396 data, 29128 bss, 0m17s run. -- LOCAL_FLAGS+=-O2 -fomit-frame-pointer -march=i686 -msse3 \ -funroll-loops -finline-functions 1. 1m37s compile, 1564884 file, 1553374 text, 6124 data, 27168 bss, 0m13s run. 2. 1m45s compile, 1625152 file, 1609475 text, 4684 data, 29160 bss, 0m15s run. 3. 1m58s compile, 1593280 file, 1577599 text, 4688 data, 29128 bss, 0m18s run. 4. 1m52s compile, 1623044 file, 1606958 text, 4396 data, 29128 bss, 0m17s run. -- LOCAL_FLAGS+=-Os -fomit-frame-pointer -march=i686 -msse3 \ -funroll-loops -finline-functions 1. 1m34s compile, 1506228 file, 1494339 text, 6124 data, 27168 bss, 0m13s run. 2. 1m05s compile, 879552 file, 863302 text, 4680 data, 29224 bss, 0m27s run. 3. 1m15s compile, 869624 file, 854430 text, 4228 data, 28996 bss, 0m25s run. 4. 1m08s compile, 957428 file, 941816 text, 3932 data, 28900 bss, 0m21s run. -- Summary: The best compiler for p7zip-4.55 is gcc-3.4.6 and its best option is -O3 -fomit-frame-pointer -march=i686 -msse3 -funroll-loops -finline-functions The compile's and run's time of gcc-3.4.6 is the fastest, and i don't know why the modern gcc4's family is little bit slower than the older gcc3's family. The gcc-4.3 snapshot is worse than gcc-4.2/gcc-4.1 in the code generation, due to its bad code size (~2.3MB) and sometimes long run time (52s). -- J.C. Pizarro
Re: Results of 7z-4.55 performance with current GCCs.
From: NightStrike <[EMAIL PROTECTED]> Date: Thu, 1 Nov 2007 22:34:33 -0400 > I think what is more important is the resulting binary -- does it > run faster? The answer to this is situational dependant. For example, for me, the speed of compilation at -O2 is very important because I'm constantly doing full tree build regressions. There are large groups of us who pine for compilation to be as fast as the old MIPS compilers were, and they were fully optimizing and even had a more advanced register allocator than GCC has now.
Re: Results of 7z-4.55 performance with current GCCs.
On 11/1/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > The compile's and run's time of gcc-3.4.6 is the fastest, and i don't know > why the modern gcc4's family is little bit slower than the older gcc3's > family. I would think it'd be only natural for a newer generational compiler to require more time to compile a large application. If you think about it in terms of what is actually going on behind the scenes, the newer compiler is running more checks, doing more optimizations, and generally working harder to produce decent, efficient, bug-free code. I think what is more important is the resulting binary -- does it run faster? Do optimizations work better? Is the resulting executable easier to debug? Is it more stable? etc etc. All of these things come with a maturing compiler (some to more degree than others, obviously). The real question is this -- what is your compiler time metric actually showing you, and what do you intend for it to show? What conclusions do you hope to draw from it?
Re: Results of 7z-4.55 performance with current GCCs.
--- David Miller <[EMAIL PROTECTED]> wrote: > From: NightStrike <[EMAIL PROTECTED]> > Date: Thu, 1 Nov 2007 22:34:33 -0400 > > > I think what is more important is the resulting > binary -- does it > > run faster? > > The answer to this is situational dependant. > > For example, for me, the speed of compilation at -O2 > is very important > because I'm constantly doing full tree build > regressions. > > There are large groups of us who pine for > compilation to be as fast > as the old MIPS compilers were, and they were fully > optimizing > and even had a more advanced register allocator than > GCC has now. > I find it hard to fathom why the OP would be concerned with compile and run times measured in minutes and seconds. I don't know how long your full tree build regressions take, but for me, a very small application will take half an hour to compile, and a large one could take all day. But if by hand tuning my code, and pushing my development tools to their limits, I can have my application finish a task in minutes where my predecessors' versions took hours (something I commonly see, perhaps by chance, with the projects I find myself working on), the savings of my clients' users' time is greater than the cost of my time by several orders of magnitude, so I don't mind waiting for a build to finish if the end product is provably correct. There is much more to both compile time and run time performance than how fast your development tools are. I expect more recent tools to take longer than the tools I used even five years ago, simply because there is much more for them to do; and as they get better, I can use more demanding parts of the language (my preferred language is C++) that simply weren't practical a few years ago. As I do this, then my tools must work harder still. It isn't only the tools, but what you do with them ... If I may state the obvious, an outstanding programmer can easily make a mediocre development tool look good, while a mediocre programmer can make even the best tools look very bad. That said, I often download open source applications (all good quality), and the GCC suite takes longer to build than all the rest combined (that is, of the ones I download), and since that finishes in but a few hours on my machine, I won't worry about how fast gcc compiles code until it takes many days to compile itself. :-) As you say, performance questions and answers depend on the situation. But I say, the single most important question is, "Is the code correct?" that is, does it produce output that is provably correct. There is no point in having an insanely fast program if it only, or even only generally, produces garbage. As important as performance is, the correctness of the code is, to my mind, infinitely more important than either compile or runtime performance! I would encourage the good folk who work on GCC to focus on making the code correct first, and only after that can be proven, worry about making it faster. Really bad things can happen to real people if my programs give incorrect results (think about things like contaminant transport, dose/risk assessments, &c., and how someone I have never met may suffer if my application gives a consultant or civil servant unreliable results). When you think about the things relevant to the work I do, you will understand why I don't care if my build times are measured in hours or days or even weeks as long as my clients' users' can work more efficiently and obtain provably correct results from my programs. Computers are cheap these days, so if I find myself too often waiting for a build to complete, I'l just get another computer to work on while I wait for the one doing the build to finish. I don't help develop GCC, but may I express to those that do that I apreciate their efforts. Cheers, Ted
Re: gomp slowness
On Thu, Oct 18, 2007 at 11:42:52AM +1000, skaller wrote: > > DO you know how thread local variables are handled? > [Not using Posix TLS I hope .. that would be a disaster] Would you please elaborate? What's wrong with the POSIX TLS implementation? Do you know of any studies? I ask, because we presently use the TLS facility extensively, and have suspected that there are significant performance problems, but haven't looked into the issue.
