similar to: [LLVMdev] Order of optimization: modulo scheduling & register allocation

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'm building a target for the intermediate language of another compiler. The other intermediate language is close to an assembly language (RTL, 1 operation per line), so I based my target off of the Mips target. However, the intermediate language i'm targetting does not support tabs before the instructions. I've looked through the files and found that the tab comes from the

I am compiling the following code for the MIPS architecture: unsigned char trunc(float f) { return (unsigned char) f; } and it produces the following assembly (directives removed for convenience: trunc: trunc.w.s $f0, $f12 mfc1 $2, $f0 jr $ra nop However, this does not seem to produce the correct output for negative numbers. When I run the following code, I get

I'm working on building a target for llvm that's the intermediate language of another compiler, so that the other compiler can benifit from llvm's optimization passes. I essentially made a copy of the mips backend, and then started changing the output to match the intermediate language of the compiler. Most of the output can be overriden, but I haven't figured out how to change

I forgot to mention, the generated file that has the tab is VPOGenAsmWriter.inc. On Sat, Sep 8, 2012 at 2:43 PM, ryan baird <ryanrbaird at gmail.com> wrote: > I'm building a target for the intermediate language of another compiler. > The other intermediate language is close to an assembly language (RTL, 1 > operation per line), so I based my target off of the Mips target.

> > I didn't realize the code was undefined, I'll let my professor know; but > for code comparison purposes we're still seeking advice on producing the > output that matches the other compilers (even if it involves doing a > translation on the .ll file or additional translation to the produced > assembly). We can't fairly compare the code if it doesn't do the

Hi all, Sorry for bothering those not interested. I found that ARM backend will insert a modulo function (like __modsi3) instead of the modulo instruction. I wonder how we can inline the modulo function into the program. Is there any OPTION we can use in the opt or llc? Thanks, Ray -------------- next part -------------- An HTML attachment was scrubbed... URL:

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/

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

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

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

Ryan, I've always been bothered by this tab character that doesn't come from the target. The line you're looking for I believe is from /utils/TableGen/AsmWriterEmitter.cpp at line 428. In my opinion the target should control whether a prefix is printed before an instruction. Thanks, Javier From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ryan

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

I just accidently sent a partially complete email, so this contains the rest (sorry!) I'm working on translating llvm's optimized intermediate code to another compiler's intermediate code, and I'm working on the PHI instruction. Here's an example phi instruction to help explain what I'm trying to do: %inc25 = phi i32 [ 1, %entry ], [ %inc, %for.body ] What I would want to

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

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 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)

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

2012/9/9 ryan baird <ryanrbaird at gmail.com>: > I'm working on building a target for llvm that's the intermediate language > of another compiler, so that the other compiler can benifit from llvm's > optimization passes. > > I essentially made a copy of the mips backend, and then started changing the > output to match the intermediate language of the compiler.

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