similar to: [LLVMdev] [RFC] Remat Enhancements

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

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

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 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(). >> >>

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()

Hi, While working on https://reviews.llvm.org/D79785, we wanted to define foldMemoryOperandImpl hook for Thumb1, that folds load, indirect call to direct call tLDRpci, tBLX -> tBL. This triggered an assertion error with expensive checks turned on in MachineVerifier because the newly created tBL insn by Thumb1InstrInfo::foldMemoryOperandImpl had memory operands of LoadMI attached by

Thanks for the details! How should we think of the case where an instruction has memory operands (in the sense that X86II::getMemoryOperandNo >=0), but doesn't have MachineMemOperands? I'm seeing an example in the case of __builtin_prefetch (lowered via SelectionDAG::getMemIntrinsicNode, which produces a MachineMemOperand) vs __builtin_ia32_gatherpfdpd, lowered through getPrefetchNode

Hello, I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions. Is it possible to have

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

Hello Mircea, > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement,

On Jan 7, 2014, at 10:47 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jan 7, 2014, at 10:40 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> >> On Dec 30, 2013, at 8:40 PM, Chris Lattner <clattner at apple.com> wrote: >> >>> >>> On Dec 30, 2013, at 4:17 PM, Hal Finkel <hfinkel at anl.gov> wrote:

I am trying to categorize the machine instructions based on associated static (i.e., as encoded in .td file) machine description and the corresponding APIs. I would like to perform appropriate actions based on the kind of instruction in a tool that I am working on. For example, I'd like to distinguish between memop instructions involving immediate vs register. While it appears that I would be

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 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

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)), > >