Displaying 8 results from an estimated 8 matches for "quanttec".
2014 Feb 03
6
[LLVMdev] ADT/Hashing.h on 32-bit platforms
On 02.02.14 00:48, Chandler Carruth wrote:
> On Sat, Feb 1, 2014 at 8:35 AM, Stephan Tolksdorf <st at quanttec.com
> <mailto:st at quanttec.com>> wrote:
>
> Hi,
>
> Currently the hashing implementation in ADT/Hashing.h produces hash
> values on 32-bit platforms that differ from the lower 32-bits of the
> hash values produced on 64-bit platforms. It seems the onl...
2014 May 11
2
[LLVMdev] [cfe-dev] Code generation for noexcept functions
On Sun, May 11, 2014 at 8:19 AM, Stephan Tolksdorf <st at quanttec.com> wrote:
> Hi,
>
> When clang/LLVM can't prove that a noexcept function only contains
> non-throwing code, it seems to insert an explicit exception handler that
> calls std::terminate. Why doesn't clang leave it to the eh personality
> function to call std::terminat...
2014 Feb 01
2
[LLVMdev] ADT/Hashing.h on 32-bit platforms
Hi,
Currently the hashing implementation in ADT/Hashing.h produces hash
values on 32-bit platforms that differ from the lower 32-bits of the
hash values produced on 64-bit platforms. It seems the only reason for
this difference is that the uint64_t integer seed is truncated to
size_t. Since the usage of uint64_t and size_t as types for seed values
in the implementation is somewhat
2013 Oct 24
1
[LLVMdev] Exploiting 'unreachable' for optimization purposes
...efforts to make better use of unreachable for optimization
purposes: http://llvm.org/bugs/show_bug.cgi?id=810
I've added a comment and assigned it to you as requested.
Thanks,
Stephan
On 24.10.13 19:05, Mark Lacey wrote:
>
> On Oct 24, 2013, at 5:22 AM, Stephan Tolksdorf <st at quanttec.com> wrote:
>
>> Hi,
>>
>> When clang/llvm compiles the following sample (with -O2) it optimizes away the second comparison in test1 but not in test2. Is this handling of 'unreachable' by purpose, or is this just a shortcoming of the current optimization passes? GCC...
2013 Oct 24
0
[LLVMdev] Exploiting 'unreachable' for optimization purposes
On Oct 24, 2013, at 5:22 AM, Stephan Tolksdorf <st at quanttec.com> wrote:
> Hi,
>
> When clang/llvm compiles the following sample (with -O2) it optimizes away the second comparison in test1 but not in test2. Is this handling of 'unreachable' by purpose, or is this just a shortcoming of the current optimization passes? GCC and MSVC (with...
2013 Oct 24
2
[LLVMdev] Exploiting 'unreachable' for optimization purposes
Hi,
When clang/llvm compiles the following sample (with -O2) it optimizes
away the second comparison in test1 but not in test2. Is this handling
of 'unreachable' by purpose, or is this just a shortcoming of the
current optimization passes? GCC and MSVC (with the equivalent code
using the __assume intrinsic) both optimize away the comparison in test2.
void f1();
void f2();
void
2015 Mar 12
3
[LLVMdev] On LLD performance
On Thu, Mar 12, 2015 at 4:52 AM, Stephan Tolksdorf <st at quanttec.com> wrote:
>
> On 11.03.2015 23:02, Rui Ueyama wrote:
>
>> An idea to make the resolver faster would be to use a concurrent hash
>> map to insert new symbols in parallel. Assuming symbols from the same
>> file don't conflict each other (I think it's a valid a...
2015 Mar 11
9
[LLVMdev] On LLD performance
I spent a week to optimize LLD performance and just wanted to share things
what I found. Also if there's anyone who have a good idea on how to make it
faster, I'd like to hear.
My focus is mainly on Windows, but my optimizations are generally platform
neutral. I aim both single-thread and multi-thread performance.
r231434 <http://reviews.llvm.org/rL231454> is a change that has the