search for: implicit_defs

Hi, Recently code using IMPLICIT_DEF and INSERT_SUBREG started to break: %vreg9<def> = IMPLICIT_DEF %vreg10<def> = INSERT_SUBREG %vreg9<kill>, %vreg1<kill>, hi %vreg12<def> = sub %vreg10<kill>, %vreg11<kill> => %vreg10<def> = IMPLICIT_DEF %vreg10:hi<def> = COPY %vreg1<kill>

I used llvm-stress to find a similar problem on x86-64. See http://llvm.org/bugs/show_bug.cgi?id=12821. BTW, llvm-stress is a great tool! /Patrik Hägglund ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jakob Stoklund Olesen Sent: den 9 maj 2012 18:21 To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev]

On May 9, 2012, at 6:27 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > Hi, > > Recently code using IMPLICIT_DEF and INSERT_SUBREG started to break: > > %vreg9<def> = IMPLICIT_DEF > %vreg10<def> = INSERT_SUBREG %vreg9<kill>, %vreg1<kill>, hi > %vreg12<def> = sub %vreg10<kill>,

Guys, I think I figure out the way that the current LLVM allocators are handling IMPLICIT_DEF's. One question more: why are you adding null length intervals to IMPLICIT_DEF instructions? If they were non-null, I think the code to handle them would be more homogeneous, e.g a traversal of the intervals during register allocation would already reveal virtuals defined implicitly. best,

Hi, I have a MachineInstr that writes to a subreg, but clobbers the superreg. How should I BuildMI this instruction? I try to do a IMPLICIT_DEF super_reg and then write to a subreg of that super register , but it gets DCE:ed. Is there a way to express this clobbering of a superregister? thanks, Jonas -------------- next part -------------- An HTML attachment was

Hi, guys. sorry if this has already been discussed, but I still feel like clarifying: how should the register allocator handle IMPLICIT_DEF instructions? The LiveIntervalAnalysis class is assigning them zero length intervals. After I removed this, e.g, by removing the lines: if (mi->getOpcode() == TargetInstrInfo::IMPLICIT_DEF) { DOUT << "is a implicit_def\n";

Hi, I'm implementing the built_vector as an IMPLICIT_DEF followed by INSERT_SUBREGs. This approach is the one of the SPARC architecture. def : Pat<(build_vector (f32 fpimm:$a1), (f32 fpimm:$a2)), (INSERT_SUBREG(INSERT_SUBREG (v2f32 (IMPLICIT_DEF)), (i32 (COPY_TO_REGCLASS (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$a1)), FPUaOffsetClass)), A_UNIT_PART),

On 4/12/2018 8:01 AM, Dominique Torette via llvm-dev wrote: > > But there is one small issue in the inference of RegisterClass of the > implicitly defined register. > > As shown below, the %vreg6<def> is implicitly defined as FPUabRegisterClass. > > This register class accepts the v2f32 type, but for others addressing > mode context this register should be

I noticed that the AsmWriter backend of TableGen is no longer handling the IMPLICIT_DEF case in printInstruction() function (by calling printImplicitDef). It was doing so in llvm 2.6. Is it supposed to be handled explicitly in printMachineInstruction()? What is the recommended method? Manjunath

Can someone explain where things like IMPLICIT_DEF_FR64 come from? I believe something is noticing a use before def and inserting some kind of bogus code to compensate. The machine instructions look like this (x86): %reg1069<def> = IMPLICIT_DEF_FR64 FsMOVLPDmr %reg0, 1, %reg0, 0, %reg1069 This is no good -- it stores to zero. Thanks. -Dave

Hi all, After a recent upstream merge into our downstream sources we are suddenly encountering the freeze instruction in LLVM IR for div/rem pairs. This seems to be related to [1]. Our downstream target is GlobalISel only and unfortunately GlobalISel doesn't support this instruction yet, so most of our internal test-suite is now breaking due to GlobalISel not being able to translate this

On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: > You need to specify sub-register == super-register, idx relationship. > See X86RegisterInfo.td: > > def x86_subreg_8bit : PatLeaf<(i32 1)>; > def x86_subreg_16bit : PatLeaf<(i32 2)>; > def x86_subreg_32bit : PatLeaf<(i32 3)>; > > def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, >

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Stellard > Sent: 19 September 2014 01:36 > To: Sanjay Patel > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] predicates vs. requirements [TableGen, > X86InstrInfo.td] > > On Thu, Sep 18, 2014 at 03:25:07PM -0600, Sanjay Patel wrote: >

On Thursday 29 January 2009 18:04, Eli Friedman wrote: > On Thu, Jan 29, 2009 at 2:47 PM, David Greene <dag at cray.com> wrote: > > After phi elimination we have: > > > > bb134: > > %reg1645 = 1.0 > > > > bb74: > > %reg1176 = MOVAPS %reg1645 > > %reg1177 = MOVAPS %reg1646 > > [...] > > > > bb108: > > %reg1645 =

On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote: > > On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote: > > > What’s the value produced by an INSERT_SUBREG node? Is it a chain? > > > No, insert_subreg returns a value: > > > v1 = insert_subreg v2, v3, idx > > > v1 and v2 will have the same type, e.g. i16, and v3 must have a >

On Jan 29, 2009, at 5:29 PM, David Greene wrote: > On Thursday 29 January 2009 18:04, Eli Friedman wrote: >> On Thu, Jan 29, 2009 at 2:47 PM, David Greene <dag at cray.com> wrote: >>> After phi elimination we have: >>> >>> bb134: >>> %reg1645 = 1.0 >>> >>> bb74: >>> %reg1176 = MOVAPS %reg1645 >>> %reg1177 =

On 7/28/2017 1:59 PM, Quentin Colombet wrote: > Hi Krzysztof, > > Thanks for digging into this. > >> On Jul 28, 2017, at 11:08 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> I've looked into that and it's not going to be simple, unfortunately. >> >> Here's the original example again: >> >> --- >>

On Oct 15, 2008, at 5:29 AM, sanjiv gupta wrote: > On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: >> You need to specify sub-register == super-register, idx relationship. >> See X86RegisterInfo.td: >> >> def x86_subreg_8bit : PatLeaf<(i32 1)>; >> def x86_subreg_16bit : PatLeaf<(i32 2)>; >> def x86_subreg_32bit : PatLeaf<(i32

Hi Venu, FWIW, I have a pass that does copy propagation after RA [1] (currently only within a basic block) that should be enabled some time in the not-too-distant future. It has been reviewed and accepted, but I'm currently working on getting a slight change to the MachineOperand representation [2] that should make the copy propagation change much simpler. I believe this change to

You need to specify sub-register == super-register, idx relationship. See X86RegisterInfo.td: def x86_subreg_8bit : PatLeaf<(i32 1)>; def x86_subreg_16bit : PatLeaf<(i32 2)>; def x86_subreg_32bit : PatLeaf<(i32 3)>; def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], [AL, CL,