search for: maystores

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

Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this

these are supposed for any instruction which could possible read/write memory? (btw, should be canload or canstore in that case :) ) this does not seem to be consistent with their use in TD files. /// mayLoad - Return true if this instruction could possibly read memory. /// Instructions with this flag set are not necessarily simple load /// instructions, they may load a value and

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 08/21/12 16:49, Jim Grosbach wrote: > > I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. > > Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( This proposal would certainly make my life easier

On Mar 18, 2008, at 6:12 PM, Dan Gohman wrote: > 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 =

> 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

On Aug 22, 2012, at 9:40 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: > On 08/21/12 16:49, Jim Grosbach wrote: >> >> I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. >> >> Beyond that, I don't see an alternative to an audit

Hi, I define a customized node with customized type. The job of this customized node is to move a value from one register class to another class. I find that if there is no use of the destination register, this node will be deleted from SDAG. For some reasons, I want to keep this node. So I attach mayStore attribute to this node and I hope it will not be deleted. However, it does not work like I

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

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

hi Tim,guys, it was regarding splitting 16-bit ADDC to two 8-bit ADDC+ADDE. the 8-bit ADDE instruction is defined as: let Constraints="$dst=$op0",mayStore=1, hasSideEffects=0,neverHasSideEffects=1 in def ADDErm: myInstr <0x0, (outs Intregs:$dst) (ins Intregs:$op0,MEMi:$op1), "", [set IntRegs:$dest (adde IntRegs:$op0, (load ADDRi:$op1))] > very unlucky, this

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

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 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. > > It's possible to override this behavior by setting neverHasSideEffects = 1. > > It was