similar to: (Question regarding the) incomplete "builtins library" of "Compiler-RT"

Displaying 20 results from an estimated 10000 matches similar to: "(Question regarding the) incomplete "builtins library" of "Compiler-RT""

2018 Nov 30
2
(Question regarding the) incomplete "builtins library" of "Compiler-RT"
"Friedman, Eli" <efriedma at codeaurora.org> wrote: > On 11/30/2018 8:31 AM, Stefan Kanthak via llvm-dev wrote: >> Hi @ll, >> >> compiler-rt implements (for example) the MSVC (really Windows) >> specific routines compiler-rt/lib/builtins/i386/chkstk.S and >> compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() >> See
2018 Nov 25
3
BUGS n code generated for target i386 compiling __bswapdi3, and for target x86-64 compiling __bswapsi2()
Hi @ll, targetting i386, LLVM/clang generates wrong code for the following functions: unsigned long __bswapsi2 (unsigned long ul) { return (((ul) & 0xff000000ul) >> 3 * 8) | (((ul) & 0x00ff0000ul) >> 8) | (((ul) & 0x0000ff00ul) << 8) | (((ul) & 0x000000fful) << 3 * 8); } unsigned long long __bswapdi2(unsigned long
2018 Nov 25
3
BUGS n code generated for target i386 compiling __bswapdi3, and for target x86-64 compiling __bswapsi2()
bswapdi2 for i386 is correct Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into eax. Those are each bswapped. The ABI for the return is edx contains bits [63:32] and eax contains [31:0]. This is opposite of how the register were loaded. ~Craig On Sun, Nov 25, 2018 at 10:36 AM Craig Topper <craig.topper at gmail.com> wrote: > bswapsi2 on the x86-64 isn't using
2018 Dec 03
3
The builtins library of compiler-rt is a performance HOG^WKILLER
Hi @ll, LLVM-7.0.0-win32.exe contains and installs lib\clang\7.0.0\lib\windows\clang_rt.builtins-i386.lib The implementation of (at least) the multiplication and division routines __[u]{div,mod,divmod,mul}[sdt]i[34] shipped with this libraries SUCKS: they are factors SLOWER than even Microsoft's NOTORIOUS POOR implementation of 64-bit division shipped with MSVC and Windows! The reasons: 1.
2014 May 27
2
[LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation
I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn't exercised much outside of MCJIT use. That said, when this assertion fails it is usually
2018 Dec 03
3
The builtins library of compiler-rt is a performance HOG^WKILLER
"Craig Topper" <craig.topper at gmail.com> wrote: > None of the "si" division routines will be used by x86. That was my expectation too. > They exist for targets that don't support the operations natively. > X86 supports them natively so will never use the library functions. So they SHOULD not be built (or at least not shipped) with the builtins library
2018 Dec 01
2
Where's the optimiser gone? (part 5.b): missed tail calls, and more...
Compile the following functions with "-O3 -target i386" (see <https://godbolt.org/z/VmKlXL>): long long div(long long foo, long long bar) { return foo / bar; } On the left the generated code; on the right the expected, properly optimised code: div: # @div push ebp | mov ebp, esp | push dword ptr [ebp + 20] | push
2013 Jan 30
1
[LLVMdev] x86 code emitter ebp and esp conflicts
Bug is reported with test cases. see http://llvm.org/bugs/show_bug.cgi?id=15124 . Thanks, -Peng On Wed, Jan 30, 2013 at 12:14 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > > Has anyone seen this problem before? and is there any fix or work around > > for that? > Please provide a testcase and fill LLVM problem report into bugzilla. > > Thanks! >
2007 Jun 24
5
[LLVMdev] alloca on Win32
Hello, Scott. > Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs
2007 Jun 24
0
[LLVMdev] alloca on Win32
Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack
2007 Jun 24
1
[LLVMdev] alloca on Win32
The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote: > > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using
2015 Jun 30
4
[LLVMdev] Crashes on Windows 8 with >4k stack frames
Hi All, we have an issue with our LLVM-based JIT compiler - executing the compiled code corrupts memory (and subsequently crashes) if we alloca more than 4k of variables (more than 511 8-byte ints). The same code works on Windows 7 (32 and 64 bit), Linux, MacOS. We compile LLVM and our program with Microsoft's Visual Studio 2010. Both debug and release builds are affected. The variables
2019 Mar 04
2
Where's the optimiser gone (part 11): use the proper instruction for sign extension
Compile with -O3 -m32 (see <https://godbolt.org/z/yCpBpM>): long lsign(long x) { return (x > 0) - (x < 0); } long long llsign(long long x) { return (x > 0) - (x < 0); } While the code generated for the "long" version of this function is quite OK, the code for the "long long" version misses an obvious optimisation: lsign: # @lsign mov
2018 Nov 25
2
BUGS n code generated for target i386 compiling __bswapdi3, and for target x86-64 compiling __bswapsi2()
I just compiled the two attached files in 32-bit mode and ran it. It printed efcdab8967452301. I verified via objdump that the my_bswap function contains the follow assembly which I believe matches the assembly you linked to on godbolt. _my_bswap: 1f70: 55 pushl %ebp 1f71: 89 e5 movl %esp, %ebp 1f73: 8b 55 08 movl 8(%ebp), %edx 1f76: 8b 45 0c movl 12(%ebp), %eax 1f79: 0f c8
2018 Dec 01
2
Where's the optimiser gone? (part 5.c): missed tail calls, and more...
Compile the following functions with "-O3 -target i386-win32" (see <https://godbolt.org/z/exmjWY>): __int64 __fastcall div(__int64 foo, __int64 bar) { return foo / bar; } On the left the generated code; on the right the expected, properly optimised code: push dword ptr [esp + 16] | push dword ptr [esp + 16] | push dword ptr [esp + 16] |
2015 Aug 16
2
[LLVMdev] Adding a stack probe function attribute
I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I
2017 Mar 05
3
Error in Windows build from release_40 branch
Hi, I'm trying to do a build and install on Windows 10 with Visual Studio 2015 Community Edition for the X86 and ARM targets, from the current release_40 branch. While compilation completes without error, the INSTALL target fails with the following error: 54> CMake Error at projects/compiler-rt/lib/builtins/cmake_install.cmake:34 (file): 54> file INSTALL cannot find 54>
2014 Jul 08
2
[LLVMdev] [compiler-rt] clang_rt.builtins-${arch} library on windows
Is there any specific reason why the clang_rt.builtins-${arch} library is disabled for windows builds? if (NOT WIN32) foreach(arch x86_64 i386 arm) if(CAN_TARGET_${arch}) set_source_files_properties(${${arch}_SOURCES} PROPERTIES LANGUAGE C) add_compiler_rt_runtime(clang_rt.builtins-${arch} ${arch} STATIC SOURCES ${${arch}_SOURCES} CFLAGS
2014 Jul 08
2
[LLVMdev] [compiler-rt] CMake bug in building ARM builtins library
On 8 July 2014 19:47, Alexey Samsonov <vonosmas at gmail.com> wrote: > compiler-rt/lib/builtins/arm/*.S files are listed in arm_SOURCES variable, > and therefore should make it into the builtins static library on ARM. Don't > they? I assume so... But I'm not an expert in CMake.
2015 Jun 30
2
[LLVMdev] Crashes on Windows 8 with >4k stack frames
We tested on 3.4.2 and 3.5.1. Later versions are slightly problematic to test since they don't compile with VS2010. Do you happen to know if it's fixed in one of the released versions, or if there is a workaround (chkstk?) or a bug report online? Thanks! Eph On 30.06.2015 12:58, Nicholas Chapman wrote: > It's a known issue. I believe it's fixed in trunk however. >