Displaying 7 results from an estimated 7 matches for "__udivti3".
Did you mean:
__udivdi3
2018 Apr 26
2
windows ABI problem with i128?
...=======
; ModuleID = 'lib/builtins/udivti3.c'
source_filename = "lib/builtins/udivti3.c"
target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64--windows-msvc19.11.0"
; Function Attrs: noinline nounwind optnone uwtable
define i128 @__udivti3(i128, i128) #0 {
%3 = alloca i128, align 16
%4 = alloca i128, align 16
store i128 %1, i128* %3, align 16
store i128 %0, i128* %4, align 16
%5 = load i128, i128* %3, align 16
%6 = load i128, i128* %4, align 16
%7 = call i128 @__udivmodti4(i128 %6, i128 %5, i128* null)
ret i128 %7
}...
2018 Apr 26
1
windows ABI problem with i128?
...> source_filename = "lib/builtins/udivti3.c"
> > target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
> > target triple = "x86_64--windows-msvc19.11.0"
> >
> > ; Function Attrs: noinline nounwind optnone uwtable
> > define i128 @__udivti3(i128, i128) #0 {
> > %3 = alloca i128, align 16
> > %4 = alloca i128, align 16
> > store i128 %1, i128* %3, align 16
> > store i128 %0, i128* %4, align 16
> > %5 = load i128, i128* %3, align 16
> > %6 = load i128, i128* %4, align 16
> > %7 = c...
2018 Apr 26
0
windows ABI problem with i128?
...b/builtins/udivti3.c'
> source_filename = "lib/builtins/udivti3.c"
> target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64--windows-msvc19.11.0"
>
> ; Function Attrs: noinline nounwind optnone uwtable
> define i128 @__udivti3(i128, i128) #0 {
> %3 = alloca i128, align 16
> %4 = alloca i128, align 16
> store i128 %1, i128* %3, align 16
> store i128 %0, i128* %4, align 16
> %5 = load i128, i128* %3, align 16
> %6 = load i128, i128* %4, align 16
> %7 = call i128 @__udivmodti4(i128 %6, i12...
2017 Oct 19
2
Why x86_64 divq is not used for 128-bit by 64-bit division?
Hi there,
Let's have this C code:
unsigned long div(unsigned __int128 n, unsigned long d)
{
return n / d;
}
I would assume that the divq is the perfect match here. But the compiler
generates the
code that calls the __udivti3 procedure which performs 128-bit by 128-bit
division.
Why is divq not used here?
- Paweł
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171019/52b9cb69/attachment.html>
2020 May 21
2
on division of __int128 bit integer
Hi Team,
I observer that division of __int128 bit is very heavy operation.
It internally call a routine '__udivti3', which internally call '
__udivmodti4'.
Due to it the overall performance is much much slower (almost 15 time
slower than if I do it via a combination of 64-bit or microsoft '_udiv128').
Also what to know if I can directly call below routine directly from my
code :
*unsigned...
2018 Jan 30
0
[compiler-rt] Support 128 bits soft-floating point without int128_t support
On 30 January 2018 at 14:12, Kito Cheng via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi all:
>
> I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem
> when adding soft float routine for rv32, RISC-V ABI required 128 bits
> bits for long double, but it's implemented by int128_t, however rv32
> don't support __int128_t.
>
> Of
2018 Jan 30
2
[compiler-rt] Support 128 bits soft-floating point without int128_t support
Hi all:
I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem
when adding soft float routine for rv32, RISC-V ABI required 128 bits
bits for long double, but it's implemented by int128_t, however rv32
don't support __int128_t.
Of cause, it not hard thing to support __int128_t by overriding
TargetInfo::hasInt128Type for LLVM, but its will cause some ABI