similar to: [LLVMdev] Random question about the x86 backend (and backends in general I suppose)

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

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

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

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

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

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

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

As many of you know, I have a growing series of patches for a RISC-V backend under/awaiting review <https://reviews.llvm.org/differential/?authors=asb&order=updated>, <http://github.com/lowrisc/riscv-llvm>. I'll be posting a larger status update on that work either later today or tomorrow, this RFC focuses on an issue that came up during review which I think may benefit from

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:

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