similar to: [LLVMdev] [LLVMDev] Is there any way to eliminate zero-extension instruction?

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

Dear developers. My question is the same as the title. Is there any way to implement target specific optimizations after instruction selection or later? I cannot find any related document. Please let me know. Thanks in advance. Minwook Ahn -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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 Eli, On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: >> Hey folks, >> >> We are having some difficulty with how we have been representing our >> predicate registers, and wanted some advice from the list.  First, we >> had been

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: > Hey folks, > > We are having some difficulty with how we have been representing our > predicate registers, and wanted some advice from the list.  First, we > had been representing our predicate registers as 1 bit (i1).  The truth, > however, is that they are 8 bits.  The reason for this is

Hey folks, We are having some difficulty with how we have been representing our predicate registers, and wanted some advice from the list. First, we had been representing our predicate registers as 1 bit (i1). The truth, however, is that they are 8 bits. The reason for this is that they serve as predicates for conditional execution of instructions, branch condition codes, and also as

Hi, A bit more information. I believe my problem lies with the fact that the load is left as 'anyext from i8'. On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! If BB#1 were to force the load to a "zext from i8" would this information be available in BB#2? BB#1: 0x268c1b0: i32 = Register %vreg1 [ID=3] 0x2689d80:

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

On Sep 10, 2013, at 8:59 AM, Robert Lytton <robert at xmos.com> wrote: > Hi, > > A bit more information. > I believe my problem lies with the fact that the load is left as 'anyext from i8'. > On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! > If BB#1 were to force the load to a "zext from i8" would

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

someguy wrote: > Hi All, > > I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; > mov rX,0; END:" sequence. > > Chris mentioned that the PPC code (as well as the x86 SSE code) does > this, but I can't seem to find it. > > What I really need to kmow is how to insert the branch/label pair at > instruction selection phase. > > Anyone

Hi All, I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; mov rX,0; END:" sequence. Chris mentioned that the PPC code (as well as the x86 SSE code) does this, but I can't seem to find it. What I really need to kmow is how to insert the branch/label pair at instruction selection phase. Anyone have an example of this?

Hello all. At XMOS we are working towards updating the upstream XCore backend for newer versions of the chip. XCore is the XMOS processor. The XCore backend was written by Richard Osborne at XMOS. Richard has moved on. The current code owner in CODE_OWNERS.TXT, Robert Lytton, has also moved on. For some years XMOS has developed the compiler in-house, for new versions of the chip, but not

Hi All, I have faced a problem with TargetLowering::SimplifyDemandedBits with AND. Here is a example as following: /* C source code */ struct A { unsigned int a; unsigned char c1, c2; bool b1 : 1; bool b2 : 1; bool b3 : 1; }; int main () { struct A x[1]; x[0].b1 = false; int s = 0; s = x[0].b1 ? 1 : 0; <--- Here is problem. if (s != 0) __builtin_abort

If I give instcombine the following IR: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %c = getelementptr [1 x i8]* %a, i32 0, i32 0 %d = getelementptr [1 x i8]* %b, i32 0, i32 0 %cmp = icmp ult i8* %c, %d ret i1 %cmp } It optimizes it into: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %cmp = icmp slt [1 x i8]* %a, %b ret i1 %cmp } Is this a bug, or are there some semantics of icmp

With LLVM built from trunk I understand I should now use llvm-config --system-libs to get the system libraries to link against when linking against llvm (as of r197664). If run this then llvm-config outputs a blank line before the system libraries, for example on Linux I get: $ llvm-config --system-libs -lz -ltinfo -lrt -ldl -lm If I use --system-libs together with --libs the LLVM libraries