similar to: [LLVMdev] About inlining the modulo function in ARM architecture

Hi Tim, Thanks for your reply. On Mon, Nov 10, 2014 at 1:26 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Ray, > > On 10 November 2014 10:13, Alex S <alexmountain13 at gmail.com> wrote: > > Sorry for bothering those not interested. I found that ARM backend will > > insert a modulo function > > (like __modsi3) instead of the modulo instruction.

On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > I can see the error, and it's just a bad selection of choices. I was > wrong in assuming that the "eabi" at the end would always force it: > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > .file "mod.c" > bl __modsi3 > bl __umodsi3 I was discussing this with Tim on IRC and he

Hi all, one issue found during the NetBSD/ARM tests is the following. Consider this input for EARM: int f(int a, int b) { return a % b; } unsigned int g(unsigned int a, unsigned int b) { return a % b; } At the moment, this will call __modsi3 and __umodsi3, even though those functions are not part of AAPCS. Should this be considered a lowering bug in the ARM target? Joerg

Hi Joerg, > At the moment, this will call __modsi3 and __umodsi3, even though those > functions are not part of AAPCS. Should this be considered a lowering > bug in the ARM target? LLVM actually supports both variants, depending on the target. The __aeabi_* functions are part of the ARM "runtime ABI" and largely independent of AAPCS. For whatever reason, Linux (& Darwin)

On Mon, Dec 09, 2013 at 03:11:45PM +0100, Joerg Sonnenberger wrote: > On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > > I can see the error, and it's just a bad selection of choices. I was > > wrong in assuming that the "eabi" at the end would always force it: > > > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > > .file

I was reading about the order of optimizations in the code generation stage here: http://llvm.org/docs/CodeGenerator.html#the-high-level-design-of-the-code-generator This is the part that's interesting to me: 3. SSA-based Machine Code Optimizations<http://llvm.org/docs/CodeGenerator.html#ssa-based-machine-code-optimizations>— This optional stage consists of a series of machine-code

On Mon, Dec 09, 2013 at 07:56:26AM +0000, Tim Northover wrote: > Hi Joerg, > > > At the moment, this will call __modsi3 and __umodsi3, even though those > > functions are not part of AAPCS. Should this be considered a lowering > > bug in the ARM target? > > LLVM actually supports both variants, depending on the target. The > __aeabi_* functions are part of the

On Jan 23, 2013, at 3:45 PM, ryan baird <ryanrbaird at gmail.com> wrote: > I was reading about the order of optimizations in the code generation stage here: http://llvm.org/docs/CodeGenerator.html#the-high-level-design-of-the-code-generator > > This is the part that's interesting to me: > > 3. SSA-based Machine Code Optimizations — This optional stage consists of a

I can't run a function which generates random numbrers using linear congruential generator. My multiplier is a=5+8^6, increment is b=1 and modulo is m=2^30. the code I have written works for modulo upto m=2^28. For m= 2^29 , it says, can not allocate memory for the vector or something like that. For m= 2^31 or more, its says the argument "for i in 1:m " is too large in

I have a problem integrating the 'standard map' ( http://en.wikipedia.org/wiki/Standard_map http://en.wikipedia.org/wiki/Standard_map ) with deSolve: By using the modulo-operator '%%' with 2*pi in the ODEs (standardmap1), the resulting values of P and Theta, should not be greater than 2pi. Because this was not the case, i was thinking that the function 'ode' has some

On Thu, Nov 14, 2013 at 01:48:17AM -0800, edwintorok wrote: > Following the link to builder.ml from your blogpost I noticed the make_random_password () function, and I have some suggestions, well nitpicks really. See the 2 commits from this pull request. > > 1. Using Ocaml&#39;s buffered I/O means that one make_random_password() call reads 64k bytes from /dev/urandom which drops the

Hi all, Could we modify the "%%" (modulo)-operator to include some tolerance for rounding-errors when supplied with doubles? It's not much work (patch supplied on the bottom), and I don't think it would break anything, only if you were really interested in analysing rounding differences. Any ideas about implementing this and overwriting base::`%%`, or would we want another

On 9 December 2013 11:51, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > Part of the concern is that the same code using / does call __aeabi_idiv > and __aeabi_uidiv. Hi Joerg, I can see the error, and it's just a bad selection of choices. I was wrong in assuming that the "eabi" at the end would always force it: $ clang -target arm-elf-eabi -S mod.c -o - |

Duncan, I think Emil realizes that the floating point format isn't able to represent certain numbers, that's why he is suggesting this change rather than complaining about our arithmetic being broken. However, I agree with you that we should not adopt his proposal. It would not make things more "user friendly" for people. Everyone has a different application and a different use

Hi, I see there is an inconsistency in LLVM libc calls. For a modulo (reminder) operation, clang -target arm-none-linux-gnueabi generates "__modsi3". clang -target arm-none-eabi generates "__aeabi_idivmod" clang -target arm-linux-androideabi generates "__modsi3" Android bionic libc doesn't provide a __modsi3, instead it provides

On 11/09/2018 11:23 AM, Emil Bode wrote: > Hi all, > > > > Could we modify the "%%" (modulo)-operator to include some tolerance for rounding-errors when supplied with doubles? > > It's not much work (patch supplied on the bottom), and I don't think it would break anything, only if you were really interested in analysing rounding differences. > >

Hello, I was wondering if anybody could help me to find swing modulo scheduling implementation in LLVM. It looks like that SMS has been implemented for SPARC V9 back end but I could not find it anywhere!! Thanks -- Mahdi Hamzeh Graduate Research Associate School of Computing, Informatics, and Decision Systems Engineering (CIDSE) Arizona State University http://www.public.asu.edu/~mhamzeh1/

Hi, Timo Sirainen wrote (May 19, 2010 1:50:34 am) : "When a connection from a newly seen user arrives, it gets assigned to a mail server according to a function: host = vhosts[ md5(username) mod vhosts_count ]" This hash function is it still used as it is without modification ? My another question sounds pretty innocent but I have doubts about vhosts_count. Taking two directors

On 7/2/2018 3:16 PM, Sanjay Patel wrote: > I also agree that the per-element rotate for vectors is what we want for > this intrinsic. > > So I have this so far: > > declare i32 @llvm.catshift.i32(i32 %a, i32 %b, i32 %shift_amount) > declare <2 x i32> @llvm.catshift.v2i32(<2 x i32> %a, <2 x i32> %b, <2 x i32> %shift_amount) > > For

Hi Ehsan, In some cases modulo scheduling will insert copy instruction that end up as real copies in the final code. It unavoidable in some cases. For example, let's say a instruction defining a value is scheduled in the first iteration, but one of its uses is scheduled two iterations later. In this case, the kernel needs to create a copy because there will be two values live in the