similar to: New intrinsic property IntrOnlyWrite

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 >

On 03/21/2016 08:54 AM, Nicolai Hähnle wrote: > 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

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

> 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

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 21 August 2017 at 11:53, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > One thing to be aware of with this is that (IIRC) tablegen uses the pattern to infer things about the pattern. One example I vaguely remember is that an empty pattern would result in the same effect as hasSideEffects=1 and I think there were others. Thanks for the note - excellent point. Looking at

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 originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more

On Aug 21, 2012, at 4:41 PM, Chris Lattner <clattner at apple.com> wrote: > Personally, I don't like the direction of making everything be redundantly specified with "let" clauses and in the patterns. I agree that it is a problem that we're not inferring from Pat<> patterns, and that not all instructions are expressible with patterns, but I'd rather we solve

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

----- Original Message ----- > From: "Craig Topper" <craig.topper at gmail.com> > To: "Chandler Carruth" <chandlerc at google.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, December 30, 2013 2:29:50 PM > Subject: Re: [LLVMdev] Random question about the x86 backend (and backends in general I suppose)

On Aug 21, 2012, at 3:45 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> I don't understand what you're saying. Are you proposing that all properties (may load, store, side effects) be explicitly added to all instructions, and the pattern only be used to produce warnings? > > Yes. > > The side effect inference is worse than the load/store inference, but

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

Hello, My out-of-tree target features some high latency instructions (let's call them FXLV). When an FXLV issues, it reserves its destination register and execution continues; if a subsequent instruction attempts to read or write that register, the pipline will stall until the FXLV completes. I have attempted to encode this constraint in the machine scheduler (excerpt at bottom of email).

On Mon, Aug 22, 2016 at 11:40 AM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Aug 22, 2016, at 11:20, Phil Tomson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > We improved our instruction itineraries and now we're seeing our > testcases for fence instructions break. > > > > For example, we have this testcase: > >

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: > >> ----- Original Message ----- >>> From: "Craig Topper" <craig.topper at gmail.com> >>> To: "Chandler Carruth" <chandlerc at google.com> >>> Cc: "LLVM

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. Hi Jakob, I don't understand what you're saying. Are you proposing that all properties (may load,

Hello, I have a problem with pattern matching on intrinsics. I have following code in IntrinsicsX86.td: ``` let TargetPrefix = "x86" in { // All intrinsics start with "llvm.x86.". def int_x86_mpx_bndmk: Intrinsic<[llvm_x86bnd_ty], [llvm_ptr_ty, llvm_i64_ty], []>; } ``` And following instruction that is generated when @llvm.x86.mpx.bndmk is used in code:

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:

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