similar to: [LLVMdev] Default/initial values for function arguments?

Thanks Quentin. I'm trying to examine from the operands of the return instruction, and then to get the last assignment of those. I thought use_iterator/reg_iterator may suit better than just loop through the machine basicblock in the reverse order. Cheng-Chih On Thu, Sep 25, 2014 at 1:51 PM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Cheng-Chih, > > On Sep 25,

Hi all, I'm trying to write a custom module-level pass that runs before AsmPrinter::EmitStartOfAsmFile(), since I'd like to have some processed information available once entering this function. Looking through "Writing an LLVM pass" documentation, it's not clear to me if this is possible. I've also tried putting the pass in different orders (addPreISel, addIRPasses,

Hi folks, I would like to find out the machine instructions that use some given registers in the reverse order, and I came across these iterators (use_iterator/reg_iterator). However, there are two things I noticed: 1) These iterators seem to traverse the machine function a bit differently from what I get from the machine function dump. In other words, the use_iterator list is not constructed in

Hi folks, I'm running into this weird issue where the register spills appear to be missing for an "if" block for some reason. For example, the original if/else blocks: --- if reg0 // storeRegToStackSlot for reg1 // do something - missing a load for reg1? else // storeRegToStackSlot for reg1 // do something // loadRegFromStackSlot for reg1 end ---- I tried looking in the LLVM

When trying to run test/CodeGen/X86/liveness-local-regalloc.ll with the command line options "-optimize-regalloc=0 -verify-machineinstrs -mcpu-atom", the test fails right after the Post-RA pseudo instruction pass with the messages *** Bad machine code: Using an undefined physical register *** - function: autogen_SD24657 - basic block: BB 0x2662d60 (BB#0) - instruction:

Hi Eli, Thanks, I’ll look into that then! Cheers, Taddeüs From: Friedman, Eli Sent: Wednesday, 2 August 2017 19:48 To: Taddeus; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Efficiently ignoring upper 32 pointer bits whendereferencing On 8/2/2017 9:03 AM, Taddeus via llvm-dev wrote: > Hi all, > > I am experiencing a problem with the representation of addresses in > the x86_64

Hi Evan, Thanks for the answers. I had few more queries though. 1. As far as I was able to understand the Codegen infrastructure, ARMInstrInfo.td file has complete description of the instructions which modify the status flags. For example, we have description for both ADD and ADDS. But the problem is that in LLVM, we have a single "ADD" Instruction. Thus when we do getDesc(add), we get

Hi, I heard that Theora will be used on OLPC. Is anyone working on optimization for OLPC? Regards, Chih-Chung Chang

Hi all, I am experiencing a problem with the representation of addresses in the x86_64 TableGen backend and was hoping someone can tell me if it is fixable. Any comments or hints in to send me in the right direction would be greatly appreciated. I am using LLVM version 3.8, commit 251286. I have an IR pass that stores metadata in the upper 32 bits of 64-bit pointers in order to implement

Hi all, I am using LLVM compiler and CodeGen for generating ARM binaries. I was going through the code for ARM backend. I noticed that the ARM Condition field( Bits 31-28) is generated by converting the conditions used in icmp and branch. For example, if I have following C Code int a,b,c,d; c = a+b; if(c==0) d = a + 10; Then I get ( Assembly Instructions with opcodes only) add *cmp*

On Jul 14, 2008, at 5:10 PM, kapil anand wrote: > Hi Evan, > > Thanks for the answers. I had few more queries though. > > 1. As far as I was able to understand the Codegen infrastructure, > ARMInstrInfo.td file has complete description of the instructions > which modify the status flags. For example, we have description for > both ADD and ADDS. But the problem is

Hi, Attached is a patch against 1.0alpha7 to speed up Theora decoding. It is about 15~20% faster in my test. It consists of following things: * MMX loop filter based on Rudolf Marek's patch in http://lists.xiph.org/pipermail/theora-dev/2005-August/002838.html * MMX IDCT based on Rudolf Marek's patch in http://lists.xiph.org/pipermail/theora-dev/2005-July/002816.html and the code in

On Jul 14, 2008, at 12:59 PM, kapil anand wrote: > Hi all, > > I am using LLVM compiler and CodeGen for generating ARM binaries. > > I was going through the code for ARM backend. I noticed that the ARM > Condition field( Bits 31-28) is generated by converting the > conditions used in icmp and branch. For example, if I have following > C Code > > int a,b,c,d;

I ran into an interesting problem when helping to land a scheduler .td file that my colleague had written. The problem that came up was that a multiply/add pair was not combined into an madd, but just for our CPU. Upon digging into it, the problem turned out to be that '(instregex "^SUB" ...' was matching "SUBREG_TO_REG" and incorrectly increasing the schedule length.

Hi, I'm still having problems implementing my custom inserter in the X86 backend. I found a solution to my last problem (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078296.html), by using a virtual register. The binary works when it's compiled in -O0, but not in -O1,-O2,... I really can't figure what I'm doing wrong... Any idea? Here is the code of my custom

Hello, I'm new to this mailing list and fixing llvm bugs for Android. Can anyone point me to any previous discussion or work related to the following bug? https://llvm.org/bugs/show_bug.cgi?id=23897 I am testing my patch to llvm to make f128 values stay in SSE registers instead of being split into two i64 values. I have tried to add a register class FR128 to hold f128 values for the x86_64

Thanks, I seem to have gotten sub-registers to work. I can't seem to suppress the zero-extend sometimes. There is no need to explicitly zero extend bytes to words on this machine as all byte operations do that. I have also gotten some memory-to-memory to work. Bagel Evan Cheng wrote: > On Mar 14, 2008, at 10:17 AM, Bagel wrote: > >> I'm trying to write a backend for a

We have a function that has 256 loads and 256 fmuladds. This block of operations is bounded at either end by an OpenCL barrier (an AMDIL fence instruction). The loads and multiply/adds are ordinarily interleaved... that is, the IR going in to code generation looks like: %39 = load float addrspace(3)* getelementptr inbounds ([16 x [17 x float]] addrspace(3)* @sgemm.b, i32 0, i32 0, i32 0), align

Hi, I write a backend and come cross an abnormal problem. Here I give a example to describe it: /////////////////////////////////////////////////////////////////////////////////////////// // A simple C function int foo() { return 1234; } ///////////////////////////////////////////////////////////////////////////////////////// When compiling foo() into my target ISA, I would expect codes

On 25 January 2018 at 15:38, ORiordan, Martin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi LLVM-Devs, > > I am considering switching to using 'llvm-lld' instead of Gnu 'ld' in a future revision of our out-of-tree target, and I am wondering is there a getting started guide for how to go about extending 'llvm-lld' to support an additional target. I