similar to: [LLVMdev] [LLVMDev] Is it possible to implement target specific optimizations which can be applied after instruction selection or later?

Yes. There are lots of examples of this. For example ARM target has a number of specific optimization passes. See ARMTargetMachine.cpp addPreEmitPass() etc. for examples of how they are added to codegen pass manager. Evan On Jan 19, 2010, at 11:34 PM, minwook Ahn wrote: > Dear developers. > > My question is the same as the title. > Is there any way to implement target specific

Dear developers. We try to make our own backend of llvm for our target machine. Assume that we have the following code in our source code. int i = ( a < b ); The code is translated into r0 <- gt r1 r2 r3 <- and r0 0x1 We think that r3 is not necessary. Is there any way to eliminate it by just modifying our backend? Thank you in advance. Minwook Ahn -------------- next part

On 20 Jan 2010, at 07:55, minwook Ahn wrote: > Dear developers. > > We try to make our own backend of llvm for our target machine. > > Assume that we have the following code in our source code. > > int i = ( a < b ); > > The code is translated into > > r0 <- gt r1 r2 > r3 <- and r0 0x1 > > We think that r3 is not necessary. Is there any way

On Tue, Jan 12, 2010 at 3:27 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Minwook Ahn, > >> We want to build our compiler based on LLVM by adding our own modules >> and functions >> >> which are specific to the features of our processor hardware. > > do you mean that you have files containing bitcode which contain useful > routines for your

Hello. I am a compiler developer of our team. We try to build our own compiler for our own processor. We want to build our compiler based on LLVM by adding our own modules and functions which are specific to the features of our processor hardware. In case of our developed modules, is it guaranteed that the modules can work in the future version of LLVM? In order to do so, what guideline is

Hi Minwook Ahn, > We want to build our compiler based on LLVM by adding our own modules > and functions > > which are specific to the features of our processor hardware. do you mean that you have files containing bitcode which contain useful routines for your processor, and that you use like a library? > In case of our developed modules, is it guaranteed that the modules can

Hi, I'm giving Adhearsion a try on a Debian Squeeze. I read here (https://github.com/adhearsion/adhearsion/wiki/Getting-Started) that the command "sudo gem install adhearsion" should "automatically add the ahn command to your system". On mine I can't run ahn without specifying full path (/var/lib/gems/1.8/bin/ahn). Did I miss something ? Regards -------------- next

While implementing a MachineFunctionPass that runs as part of the ARMTargetMachine::addPreEmitPass(), I've run into a problem. This particular MFP can drastically increase the size (in MachineInstr count) of the MachineFunction that it processes, so much so that there is a real danger of pcrel calls and branches that use immediate offsets to not be sufficient. A naive test confirmed that

Hi, I want to add Target Specific MachineFunctionPass so that it will run during Link Time Optimization. The pass is currently running in non-LTO compilation (added in addPreEmitPass). What do I need to do in order to run my pass also during LTO? Thanks, Oren --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may

Hello, I have a question about Rpad Server Installation on Windows XP. Here is a guide http://www.rpad.org/Rpad/ServerNotes.html and I have been reading this more than ten times to figure this out, but still having trouble executing a Rpad website properly. Problem: for example, if I go to http://loclhost/Rpad/example1.rpad, I can see the whole website with the page loading sign staying on

To the R development team: First of all, thank you so much for maintaining wonderful R software. Perhaps, Dr. Ahn has just reported an error on the wilcox.test() function, and suggesting that an error may arise from abs() and rank(). I just had a quick check that the problem may come from the precision of the results of arithmetic functions. 87.7-89.1+1.4 # > 87.7-89.1+1.4 # [1]

On Tue, Apr 23, 2013 at 10:29:32AM +0400, Anton Korobeynikov wrote: > Hello > > There is not support for big endian ARM at all. I guess he need to change the data layout string in ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) from "e" to "E" to get big endian output? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information

Yes, I have done exactly the same. The wawanalyzer is the same. I changed ARM.h and ARMTargetMachine.cpp in the tager/arm folder. then I make tool/llc and lib folder. On Tue, Nov 17, 2015 at 10:55 AM, John Criswell <jtcriswel at gmail.com> wrote: > On 11/17/15 12:16 AM, fateme Hoseini via llvm-dev wrote: > > Hi, > So, I run my pass in X86 target with llc command and it printed

In polr.R the (several) functions gmin and fmin contain the code > theta <- beta[pc + 1L:q] > gamm <- c(-100, cumsum(c(theta[1L], exp(theta[-1L]))), 100) That's bad. There's no reason to suppose beta[pc+1L] is larger than -100 or that the cumulative sum is smaller than 100. For practical datasets those assumptions are frequently violated, causing the

> I guess he need to change the data layout string in > ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) > from "e" to "E" to get big endian output? That would be a start, but I'd expect a significant number of bugs where the backend writers have assumed ARM was little-endian (lib/Target/Mips, which *does* support both, has many more endian checks in the

Hello There is not support for big endian ARM at all. On Tue, Apr 23, 2013 at 9:26 AM, gamma_chen <gamma_chen at yahoo.com.tw> wrote: > The llvm ARM backend is little endian elf output as my examination as > below. Is it support bid endian by other llc options as below? > > llc -filetype=obj -march=arm // little endian > llc -filetype=obj -march=? or -otheroption=? // to

Hi, I've been trying to set up clang/LLVM to compile for big endian ARM and I need a little help. The code generation works for the most part and most of my regression tests pass, but I noticed that code like this extern void g(void); int *p; int main() { if (*p & 0x01000000) g(); } generates ldr r0, [r0] ldrb r0, [r0, #3]

The llvm ARM backend is little endian elf output as my examination as below. Is it support bid endian by other llc options as below? llc  -filetype=obj -march=arm // little endian llc  -filetype=obj -march=? or -otheroption=? // to output big endian Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 1/7/2013 2:15 PM, Xu Liu wrote: > > This would be ideal. How can I do the instrumentation pass after the > instruction scheduling? You could derive your own class from TargetPassConfig, and add the annotation pass in YourDerivedTargetPassConfig::addPreEmitPass. This will add your annotation pass very late, just before the final code is emitted. If you're using the X86 target,

On Saturday, June 02, 2012 10:20:03 AM Richard Pennington wrote: > Hi, > > I've been trying to set up clang/LLVM to compile for big endian ARM and I > need a little help. The code generation works for the most part and most of > my regression tests pass, but I noticed that code like this > > extern void g(void); > int *p; > > int main() > { > if (*p