similar to: compiler-rt incorrect for this udivmodti4 case?

Displaying 20 results from an estimated 100 matches similar to: "compiler-rt incorrect for this udivmodti4 case?"

2018 Apr 25
0
compiler-rt incorrect for this udivmodti4 case?
> On Apr 25, 2018, at 12:33 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Here is my test case: > > #include <stdio.h> > > int main(int argc, char **argv) { > tu_int a = (tu_int)0x1ec273014 << 64 | 0xff7377ffffffffffuLL; > tu_int b = (tu_int)0x8ac7230489e80000uLL; > tu_int r; > tu_int q = __udivmodti4(a,
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
2018 Apr 26
2
windows ABI problem with i128?
I'm trying to use LLVM to create compiler-rt.o on Windows. I use this command from the compiler-rt project: [nix-shell:~/downloads/llvm-project/compiler-rt]$ clang -nostdlib -S -emit-llvm lib/builtins/udivti3.c -g -target x86_64-windows -DCRT_HAS_128BIT The resulting LLVM IR is: ================================================================= ; ModuleID = 'lib/builtins/udivti3.c'
2018 Apr 26
0
windows ABI problem with i128?
Most probably you need to properly specify the calling convention the backend is using for calling the runtime functions. Or implement the stub for udivti3 that performs the necessary argument lifting. I guess there is no standard ABI document describing the intended calling convention here, so I'd just do what mingw64 does here and make everything here compatible. On Thu, Apr 26, 2018 at
2018 Apr 26
1
windows ABI problem with i128?
On Thu, Apr 26, 2018 at 3:44 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Most probably you need to properly specify the calling convention the > backend is using for calling the runtime functions. Thanks for the tip. Can you be more specific? Are you suggesting there is some config parameter I can set before running TargetMachineEmitToFile? Do you know what
2020 Aug 30
5
BUG: complete misunterstanding of the MS-ABI
Objects compiled for the MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t
2003 Dec 18
2
x100P incoming
Hi Gurus How do I make x100P does not answer incoming calls ? I want * play dead for incoming calls. I do not have any context for incoming calls from x100p, in zapata.conf. Call also get logged into the CDR, that too I do not want. I am using x100p for outgoing calls only. Any help appreciate. Cheers SW
2014 Nov 22
1
Get rid of printf format warning format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
Hello. Use <inttypes.h> PRIx64 instead of llx to get rid of gcc warning format ?%llx? expects type ?long long unsigned int?, but argument 2 has type ?uint64_t? -- MartinS diff --git a/com32/gpllib/acpi/xsdt.c b/com32/gpllib/acpi/xsdt.c index 208abc6..228b6c3 100644 --- a/com32/gpllib/acpi/xsdt.c +++ b/com32/gpllib/acpi/xsdt.c @@ -63,7 +63,7 @@ int parse_xsdt(s_acpi * acpi) /*
2008 Sep 01
1
[PATCH 1/4 v2] PCI: introduce new base functions
Some basic changes to allocation bus range, MMIO resource for SR-IOV device. And add new sysfs entry to hotplug core to pass parameter to a slot, which will be used by SR-IOV code. Signed-off-by: Yu Zhao <yu.zhao at intel.com> Signed-off-by: Eddie Dong <eddie.dong at intel.com> --- drivers/pci/bus.c | 63 +++++++++++++-------------
2008 Sep 01
1
[PATCH 1/4 v2] PCI: introduce new base functions
Some basic changes to allocation bus range, MMIO resource for SR-IOV device. And add new sysfs entry to hotplug core to pass parameter to a slot, which will be used by SR-IOV code. Signed-off-by: Yu Zhao <yu.zhao at intel.com> Signed-off-by: Eddie Dong <eddie.dong at intel.com> --- drivers/pci/bus.c | 63 +++++++++++++-------------
2008 Sep 01
1
[PATCH 1/4 v2] PCI: introduce new base functions
Some basic changes to allocation bus range, MMIO resource for SR-IOV device. And add new sysfs entry to hotplug core to pass parameter to a slot, which will be used by SR-IOV code. Signed-off-by: Yu Zhao <yu.zhao at intel.com> Signed-off-by: Eddie Dong <eddie.dong at intel.com> --- drivers/pci/bus.c | 63 +++++++++++++-------------
2008 Sep 27
1
[PATCH 2/6 v3] PCI: add new general functions
Centralize capability related functions into several new functions and put PCI resource definitions into an enum. Cc: Jesse Barnes <jbarnes at virtuousgeek.org> Cc: Randy Dunlap <randy.dunlap at oracle.com> Cc: Grant Grundler <grundler at parisc-linux.org> Cc: Alex Chiang <achiang at hp.com> Cc: Matthew Wilcox <matthew at wil.cx> Cc: Roland Dreier <rdreier at
2008 Sep 27
1
[PATCH 2/6 v3] PCI: add new general functions
Centralize capability related functions into several new functions and put PCI resource definitions into an enum. Cc: Jesse Barnes <jbarnes at virtuousgeek.org> Cc: Randy Dunlap <randy.dunlap at oracle.com> Cc: Grant Grundler <grundler at parisc-linux.org> Cc: Alex Chiang <achiang at hp.com> Cc: Matthew Wilcox <matthew at wil.cx> Cc: Roland Dreier <rdreier at
2013 Oct 31
3
[releng_10 tinderbox] failure on i386/pc98
TB --- 2013-10-31 19:50:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-10-31 19:50:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-31 19:50:43 - starting RELENG_10 tinderbox run for i386/pc98 TB --- 2013-10-31 19:50:43 - cleaning the
2012 Aug 20
13
[PATCH 00/12] Multidisk support
Hello, the following patches should get multidisk access working. The syntax accepted is the following: (hdx,y)/path/to/file where x is the disk number and start at 0 and the y is the partition number starting at 1. So (hd0,1) is the first partition of the first disk. the other accepted syntax is using MBR's 32 bits disk signature so for example: (mbr:0x12345678,2)/foo/bar would address
2017 Oct 25
2
linkonce expected behavior?
http://llvm.org/docs/LangRef.html#linkage-types says: Globals with “linkonce” linkage are merged with other globals of the same name when linkage occurs. This can be used to implement some forms of inline functions, templates, or other code which must be generated in each translation unit that uses it, but where the body may be overridden with a more definitive definition later. Unreferenced
2017 Oct 25
2
linkonce expected behavior?
On Tue, Oct 24, 2017 at 9:27 PM, Vedant Kumar <vsk at apple.com> wrote: > Unreferenced linkonce globals are allowed to be discarded. > > > Is __udivmodti4 referenced? > It's referenced by a different .o file, but nothing within the module. My confusion comes from the missing direct object in the sentence. Referenced by a function local to the module? Referenced by any
2015 Apr 16
2
[PATCH 6/6] mmu: gk20a: implement IOMMU mapping for big pages
Two questions -- (a) What's the perf impact of doing this? Less work for the GPU MMU but more work for the IOMMU... (b) Would it be a good idea to do this for desktop GPUs that are on CPUs with IOMMUs in them (VT-d and whatever the AMD one is)? Is there some sort of shared API for this stuff that you should be (or are?) using? -ilia On Thu, Apr 16, 2015 at 7:06 AM, Vince Hsu <vinceh
2020 Aug 21
2
Clang is a resource hog, the installers for Windows miss quite some files, and are defect!
"David Greene" <dag at hpe.com> wrote: > Stefan Kanthak via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> "Michael Kruse" <llvmdev at meinersbur.de> wrote: >> >>> I think David is not referring to the capitalization of file names, but to >>> "DUPLICATE", "WASTING", "NOT AMUSED",
2020 Aug 21
3
Clang is a resource hog, the installers for Windows miss quite some files, and are defect!
"Philip Reames" <listmail at philipreames.com> wrote: > Stefan, > > I can't tell if you're intentionally trolling, or are simply oblivious, > but to this observer you have clearly crossed well over the line of > acceptable behavior. Since you seem to have some experience in taking the point of view of a third person: do you find LLVM's