search for: srcregs

On Sep 5, 2014, at 10:21 AM, Juergen Ributzka <juergen at apple.com> wrote: > clearKillFlags seems a little "overkill" to me. In this case you could just simply transfer the value of the kill flag from the SrcReg to the DstReg. We are extending the live-range of SrcReg. I do not see how you could relate that to the kill flag of DstReg. Therefore, I still think, this is the

Jim/Tim/Renato, A few days ago (has it been weeks now?) we discussed a codegen problem on armv4t having to do with lo->lo register copies. I'd like to start that discussion again, this time with a patch. A brief summary of the problem for folks who didn't catch the discussion earlier, and those like me who forget what they ate for breakfast: ;] The mov instruction on armv4t

Chris Lattner wrote: > On Sat, 13 May 2006, Vladimir Prus wrote: >> in LLVM CVS the afore-mentioned function has 'const TargetRegisterClass*' >> parameter, that is not documented. >> >> Can somebody explain what does it mean? > > Basically, it gives the target more information about the spill. In > particular, it specifies the register class to use

This code or subtle variations of it appears in multiple targets. It tries to convert from a register to a register class using getRegClass, but getRegClass is really supposed to take a register class enum value and get the register class object for it. It doesn't convert a register to a class. In fact there's not always a single or canonical class for a given register. What is the right

Hi All. I'm writing storeRegToStackSlot and loadFromStackSlot function for my Target. This Target can store/load one byte (not all word) from FrameIndex. If I need to store 16 bit register I will must to split it to two instruction like this: BuildMI(MBB, MI, dl, get(Z80::LD8xmr)) .addFrameIndex(FrameIndex).addImm(0) .addReg(SrcReg, 0, Z80::subreg_lo); BuildMI(MBB, MI, dl,

Hi, Paul Curtis wrote: > If you read the Arm Architecture document for ARMv5, it states for MUL: > > "Operand restriction: Specifying the same register for <Rd> and <Rm> was > previously described as producing UNPREDICTABLE results. There is no > restriction in ARMv6, and it is believed all relevant ARMv4 and ARMv5 > implementations do not require this

Hi, > I am using a cross compiler to compiler for the arm5 architecture. For this > architecture it is not allowed that a destination register is also used as source > register. > In 2007 a patch was discussed at the mailing list, however my compiler still is > producing this result. Does anyone know if this patch is actually applied? > > * I use the following arguments:

Hi Quentin, Jonas looked further into the problem below, and asked me to submit his patch. Note the we have our own out-of-tree target, and we have not been able to reproduce this problem on an in-tree target. /Patrik Hägglund [MachineSinking] Conservatively clear kill flags after coalescing. This solves the problem of having a kill flag inside a loop with a definition of the register prior to

Hi, I am using a cross compiler to compiler for the arm5 architecture. For this architecture it is not allowed that a destination register is also used as source register. In 2007 a patch was discussed at the mailing list, however my compiler still is producing this result. Does anyone know if this patch is actually applied? * I use the following arguments: llvm-gcc -mfpu=vfp -mlittle-endian

I'm working on a target based on the MIPS target, and when I copy f64 values into 32 bit registers for calling functions, I need the operation to work on a of 32 bit registers (because the language I'm translating to isn't actually mips). I've been looking at how to do this, but I haven't been able to figure it out. Since the Mips target code is still really close to mine,

Hi, The PHI elimination pass calls the function copyRegToReg for copy placement and then later tries to setkill to the temporary virtual register used in copy placement. For this setkill action it looks only in one instruction (last instruction for copyRegToReg) for virtual register with no use. My target has only one register and I can't do copyRegToReg in one instruction only. So I

Hi Dmitriy, As you've seen our current spill code assumes that spill/reloads are single instructions. I think the best way to work around this is to introduce load/store pseudo-instructions and expand these after register allocation. Cheers, Lang. On Sat, Feb 23, 2013 at 12:15 AM, Dmitriy Limonov <earl at excluzive.ws> wrote: > Hi All. > > I'm writing

Ryan, I don't think I fully understand the problem you described, but please see the comments below. Hope this helps you solve the problem. On Sat, Oct 6, 2012 at 3:18 PM, ryan baird <ryanrbaird at gmail.com> wrote: > I'm working on a target based on the MIPS target, and when I copy f64 > values into 32 bit registers for calling functions, I need the operation to > work

On Jun 15, 2010, at 2:48 PM, Jakob Stoklund Olesen wrote: > I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer.

Hi, We're having an issue with TailDuplication in our out-of-tree target and it's this PHI-node that seems to be the cause of the trouble: %vreg2<def> = PHI %vreg0, <BB#2>, %vreg1, <BB#3>; rN:%vreg2 aNlh_0_7:%vreg0 aNlh_rN:%vreg1 Note that the defined %vreg2 has register class "rN" while the read %vreg0 has register class "aNlh_0_7".

Hi LLVM, IRBuilder can fold constants (that behaviour can be controlled by Folder type). What do you think about optionally allow IRBuilder to eliminate no-op instructions like `add %a, 0` or `memcpy(%a, %b, 0)`? - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/4f99a092/attachment.html>

I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. The COPY instruction handles subreg operations with less

Why are you reverting patches for any area that you have no authorization for ? No build was broken. This patch is fine. I am authorized to check in to the Mips area and Daniel is the maintainer for that area. On 06/08/2014 02:13 AM, Alp Toker wrote: > Author: alp > Date: Sun Jun 8 04:13:42 2014 > New Revision: 210424 > > URL:

Hi, It looks like LiveIntervals::addIntervalsForSpills does not update all of the LiveIntervals infos quite correctly. In particular, if a live interval L is defined by Reg<-Reg copy instructions whose srcReg is later spilled by the addIntervalsForSpills() function, its VNInfo information is not updated in a proper way. It still points to the same MachineInstr as before, even though the

Hi Lang. Thank you. I added pseudo-instructions for spill/reloads and expanded it in expandPostRAPseudo. Regards, Dmitriy. 04.03.2013 8:24, Lang Hames wrote: > Hi Dmitriy, > > As you've seen our current spill code assumes that spill/reloads are > single instructions. I think the best way to work around this is to > introduce load/store pseudo-instructions and expand these