similar to: New to LLVM. Need help generating assembly

> On Dec 5, 2018, at 22:15, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 12/05/2018 07:22 PM, m m via llvm-dev wrote: >> Hi, >> I'm new to LLVM and need some help. I defined an instruction to increment the stack pointer by 'amount' (i.e. sp = sp + amount). During assembly generation, the string that gets emitted is "ADS $SP"

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > That's great, but I really wish you would discuss the design of these > things publicly, and not develop features on long-running secret > branches. If you secretly start out in the wrong direction, you could > be wasting a lot of your time. I don't have a choice. I have to get patches approved after I already have

dag at cray.com (David A. Greene) writes: >>> The change requires that live interval analysis be able to determine >>> whether and instruction is a load and whether an instruction writes to >>> memory. >> >> Just use MI->mayLoad(), MI->mayStore(). > > Does this also account for arithmetic instructions with memops? These > interfaces

On 19.03.2016 16:25, Mehdi Amini wrote: > Hi, > > Can you elaborate what is the impact at the IR level? > If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize the lowering for any intrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get

Hi, I'd like to draw your attention to http://reviews.llvm.org/D18291, in which I propose a new intrinsic property for intrinsics that are lowered to instructions that mayStore, but are neither mayLoad nor hasSideEffects. This is relevant for AMDGPU, where we have store instructions that don't operate on pointers. The codegen backend understands these perfectly well as stores, and so

> On Mar 21, 2016, at 9:14 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote: >> >> On 19.03.2016 16:25, Mehdi Amini wrote: >>> Hi, >>> >>> Can you elaborate what is the impact at the IR level? >>> If the point is just about

The new SUBREG target-independent instructions aren't getting mayLoad/mayStore flags set correctly. For example, in the generated X86GenInstrInfo.inc file, there is only one entry for INSERT_SUBREG: { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the

On Feb 27, 2012, at 9:51 AM, David A. Greene wrote: > dag at cray.com (David A. Greene) writes: > >>>> The change requires that live interval analysis be able to determine >>>> whether and instruction is a load and whether an instruction writes to >>>> memory. >>> >>> Just use MI->mayLoad(), MI->mayStore(). >> >>

On Sat, 23 Jun 2012 22:28:55 +0100 Tim Northover <t.p.northover at gmail.com> wrote: > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > > Working on a target I added this pattern: > > > > def : Pat<(v4i64 (load xoaddr:$src)), > > (QVFCTIDb (QVLFDXb xoaddr:$src))>; > > > > I'd like to fix this so that it works

Hi Quentin, I get following error from MachineVerifier: # End machine code for function f. *** Bad machine code: Missing mayLoad flag *** which comes from: // Check the MachineMemOperands for basic consistency. for (MachineMemOperand *Op : MI->memoperands()) { if (Op->isLoad() && !MI->mayLoad()) report("Missing mayLoad flag", MI); if (Op->isStore()

On Sat, 23 Jun 2012 21:25:48 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > On Sat, 23 Jun 2012 21:18:37 -0500 > Hal Finkel <hfinkel at anl.gov> wrote: > > > On Sat, 23 Jun 2012 22:28:55 +0100 > > Tim Northover <t.p.northover at gmail.com> wrote: > > > > > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > > > >

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

Having worked with a few people to better understand the tablegen descriptions of instructions and patterns in LLVM's backend and looking at x86's pretty heavily, I have some questions: 1) Are there instruction definition flags that are really just "when needed"? I'm thinking of things like "mayLoad" which is really alarmingly missing from a bunch of instructions

On Sat, 23 Jun 2012 21:18:37 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > On Sat, 23 Jun 2012 22:28:55 +0100 > Tim Northover <t.p.northover at gmail.com> wrote: > > > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > > > Working on a target I added this pattern: > > > > > > def : Pat<(v4i64 (load xoaddr:$src)), > >

On 19.03.2016 14:47, Philip Reames wrote: > I'm generally in support of this change. I haven't looked at the patch > yet, but the direction seems worthwhile. > > Note that we already have a writeonly predicate in a few places in the > code (BasicAA being one). If we do introduce the new intrinsic > property, we should refactor all of these places to use the new >

I have a set of changes that enhances rematerialization to handle more kinds of loads, specifically loads with multiple address registers. This is a big win for some codes on x86. I plan to send these up ASAP but I want to solicit a bit of guidance first. The change requires that live interval analysis be able to determine whether and instruction is a load and whether an instruction writes to

On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > Working on a target I added this pattern: > > def : Pat<(v4i64 (load xoaddr:$src)), > (QVFCTIDb (QVLFDXb xoaddr:$src))>; > > I'd like to fix this so that it works correctly: the TokenFactor > inputs should be attached to all inner-most instructions. I'm guessing > this is somewhere in

On Feb 23, 2012, at 8:14 AM, David Greene <dag at cray.com> wrote: > I have a set of changes that enhances rematerialization to handle more > kinds of loads, specifically loads with multiple address registers. > This is a big win for some codes on x86. That's great, but I really wish you would discuss the design of these things publicly, and not develop features on

On Aug 21, 2012, at 3:02 PM, Chris Lattner <clattner at apple.com> wrote: > > On Aug 21, 2012, at 2:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> All, >> >> TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. >

> I also had to include II.canFoldAsLoad to make this work for me. As is > the case with other "simple" loads in the PowerPC backend, > canFoldAsLoad is set but mayLoad is not (is this wrong)? Hmm. So far we've got: mayLoad, mayStore, canFoldAsLoad and hasUnmodeledSideEffects as candidates. Looking at Target.td, I see that I missed hasCtrlDep which seems to be exactly what