similar to: [LLVMdev] Kill-flag in two-address instruction tied operands

On Jul 14, 2009, at 12:10 PM, Jakob Stoklund Olesen wrote: > Hi, > > Two-address instructions are represented as normal three-address > instructions with a Desc bit that indicates the first two operands are > tied together. The question is, should the second operand have a > <kill> flag? > > a: %R0<def> = MUL %R0, %R1<kill> > b: %R0<def> = MUL

Hi, I'm working on the iterated register coalescing graph coloring allocator and try to test it with all backends available currently in LLVM. Initial tests with most of the backends are successful. It turned out that my allocator triggers a specific assertion in the RegScavenger and only for the ARM target. It looks like the LR register is used for frame pointer related things, but it is

I am trying to locate a bug that affects my Blackfin backend. I am having some trouble understanding the semantics of def/kill flags on machine operands when using subregisters. I compile this function: define void @i56_ls(i56 %x) nounwind { store i56 %x, i56* @i56_s ret void } And get this initial machine code: Live Ins: %R0 %R1 %reg1025D<def> = MOVE %R1 %reg1024D<def> =

Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > I would like to add one more case here: Fixed register operands. > > Some instructions, like x86's MUL and DIV, take operands in fixed > registers. Currently, we handle that with COPY instructions to and > from the fixed registers, but that is making code motion passes more > complicated than

On Apr 25, 2013, at 4:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > >> I would like to add one more case here: Fixed register operands. >> >> Some instructions, like x86's MUL and DIV, take operands in fixed >> registers. Currently, we handle that with COPY

Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 25.04.2013 18:58:05: > On Apr 25, 2013, at 4:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > > > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > > > >> I would like to add one more case here: Fixed register operands. > >> > >> Some

On Apr 23, 2013, at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > There are two core issues. First, the tied operands are an artifact of the way we do instruction selection for the compiler. They’re how we represent read-modify-write operands, basically. The assembler shouldn’t have to know or care about them at all. Specifically, they shouldn’t even be represented at all as an

Hello everyone, I am running into an obscure issue with ExpandPostRA. Does anyone recognizes the following: The pass replaces a real copy with a "transfer" instruction: ********** EXPANDING POST-RA PSEUDO INSTRS ********** ********** Function: main real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, %D7<imp-def> replaced by:

On Jul 8, 2012, at 3:42 PM, Sergei Larin <slarin at codeaurora.org> wrote: > ********** EXPANDING POST-RA PSEUDO INSTRS ********** > ********** Function: main > real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, > %D7<imp-def> > replaced by: %R15<def> = TFR %R4, %D7<imp-def> > > The R4 is a subreg of D2 double

On Apr 22, 2009, at 12:03 AM, Jakob Stoklund Olesen wrote: > I am trying to locate a bug that affects my Blackfin backend. I am > having some trouble understanding the semantics of def/kill flags on > machine operands when using subregisters. > > I compile this function: > > define void @i56_ls(i56 %x) nounwind { > store i56 %x, i56* @i56_s > ret void > } >

This patch adds parameter "EliminateFI" to RegScavenger::scavengeRegister, which tells register scavenger not to eliminate frame index of the emergency spill slot if set to false. I have pseudo load, store and copy instructions which are generated during register allocation and expanded post-RA but before the final stack size is known. I use register scavenger to search for a temporary

On Mar 25, 2013, at 12:04 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This patch adds parameter "EliminateFI" to RegScavenger::scavengeRegister, which tells register scavenger not to eliminate frame index of the emergency spill slot if set to false. > > I have pseudo load, store and copy instructions which are generated during register allocation and expanded

Hi again! On 08/06/2012 17:11, Ivan Llopard wrote: > Hi Sergei, Jakob, > > Thanks for your comments ! > > On 07/06/2012 20:41, Sergei Larin wrote: >> >> Jakob, >> >> Please see my comments below. Hope this helps. >> >> Sergei >> >> -- >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. >>

On Feb 4, 2013, at 8:59 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> The intention was to identify code that may have been converted from >> the old style a little too quickly. I wanted to avoid bugs from a >> global s/setIsInsideBundle/bundleWithPred/g search and replace. > > This is a good intent. Maybe a bit temporal but

Hi Sergei, Jakob, Thanks for your comments ! On 07/06/2012 20:41, Sergei Larin wrote: > > Jakob, > > Please see my comments below. Hope this helps. > > Sergei > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > *From:*Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > *Sent:* Thursday, June 07, 2012 1:02 PM > *To:* Sergei

On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> >> To: "Akira Hatanaka" <ahatanak at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> >>

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH]

Jakob, > The intention was to identify code that may have been converted from > the old style a little too quickly. I wanted to avoid bugs from a > global s/setIsInsideBundle/bundleWithPred/g search and replace. This is a good intent. Maybe a bit temporal but sound nevertheless. > finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, > LastMI)' which ought to

On Mon, 2011-12-05 at 13:18 -0800, Jakob Stoklund Olesen wrote: > On Dec 5, 2011, at 12:56 PM, Hal Finkel wrote: > > > RegScavenger is complaining about use of an undefined register, CTR8, in > > the BCTR8 instruction, in the following instance (this is from the PPC > > backend): > > > > BB#38: derived from LLVM BB %for.end50 > > Predecessors

On Dec 5, 2011, at 12:56 PM, Hal Finkel wrote: > RegScavenger is complaining about use of an undefined register, CTR8, in > the BCTR8 instruction, in the following instance (this is from the PPC > backend): > > BB#38: derived from LLVM BB %for.end50 > Predecessors according to CFG: BB#36 > %X3<def> = LD 0, <fi#27>; mem:LD8[FixedStack27] >