search for: hassideeffect

...ntrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get TableGen to shut up about what it reasonably believes to be a mismatch between the properties of the intrinsic (which it conservatively believes to be mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction (which is correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0). Indeed, write-only without an ArgMemOnly property may well be useless at the IR level. If you think that there is a better way to explain the situation to TableGen, please let me know. Pleas...

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 CodeGenDAGPatterns.cpp, it seems in the absence of a pattern hasSideEffects will be 1, while mayLoad and mayStore default to 0. Back in 2012, Jakob Stoklund Olesen added the guessInstructionProperties flag, which c...

...less the IR level attributes. >> >> As I explained in my reply to Philip, what I really need is a way to get TableGen to shut up about what it reasonably believes to be a mismatch between the properties of the intrinsic (which it conservatively believes to be mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction (which is correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0). > > I'm not sure what is the semantics of "hasSideEffects" at the MI level. I'm surprised we can consider correct that something that writes to memory is not "having...

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 we can enable better scheduling decisions than if we forced these instruction to hasSideEffects. In a perfect world, we'...

...m I pushing for IntrWriteOnly? I suspect the merely IntrWriteOnly without a functional ArgMemOnly does not provide a lot of opportunity for optimization at the IR level. However, the codegen backend does understand the resulting hardware instructions, which are marked mayLoad = 0, mayStore = 1, hasSideEffects = 0. Having mayLoad = 0 and hasSideEffects = 0 makes a difference for instruction scheduling. If you try to map the intrinsic as-is, without IntrWriteOnly, onto such hardware instructions, TableGen will (correctly) complain about a mismatch of mayLoad and hasSideEffects. So I'd like to d...

...ns after the intrinsic, and this should hold after any optimization in opt and llc. Can anyone tell me if this is something available in the current LLVM infrastructure and if so, what should be the correct way to create this intrinsic/pseudo instruction? Which bit should be set to 1? isBarrier or hasSideEffects or both? I cannot find the documentation for these 2 bits other than the comments in Target.td, so I'd like to have some explanation here. Thank you so much for your help, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pi...

...InstrWriteOnly and ArgMemOnly. It's not quite as powerful as having a writeonly argument attribute, but it's better than where we are today. > > However, the codegen backend does understand the resulting hardware > instructions, which are marked mayLoad = 0, mayStore = 1, > hasSideEffects = 0. Having mayLoad = 0 and hasSideEffects = 0 makes a > difference for instruction scheduling. > > If you try to map the intrinsic as-is, without IntrWriteOnly, onto > such hardware instructions, TableGen will (correctly) complain about a > mismatch of mayLoad and hasSideEffects...

...s pass needs to be made aware that this is not safe. The current test in the MachineLICM is as follows: // Ignore stuff that we obviously can't hoist. if (TID.mayStore() || TID.isCall() || TID.isReturn() || TID.isBranch() || TID.hasUnmodeledSideEffects()) return false; Setting hasSideEffects = 1 seems to work, but I'm not sure if that's the intended use of this flag. I notice that divide / remainder instructions for other architectures are not marked in this way. Also it is also pessimistic: if the divisor is know to be non zero then the instruction couldn't trap and w...

Hi Evan. The hasSideEffects method I believe operates only on Inline Assembly (IA) blocks. What if such a sequence is not part of IA? Thanks. Girish. If an instruction is marked as side-effect free then it's a candidate for CSE. Try marking the instruction with hasSideEffects. > >Evan > >On Dec 17, 2011, a...

Hi Tim, Thank you a lot for your reply. So IIUC, optimization passes in opt do not reorder IR instructions, only passes in llc that move MIR instructions around. Is it correct? On the back-end (llc) side, hasSideEffects might prevent some reordering. But I just learn about TargetInstrInfo::isSchedulingBoundary. Can you tell me what are the differences between the two please? Thank you very much (again), Son Tuan Vu On Mon, Sep 17, 2018 at 12:13 PM Tim Northover <t.p.northover at gmail.com> wrote: >...

...all instructions are expressible with patterns, but I'd rather we solve *those* problems than throw out inference. After discussing this, we have reached a workable compromise. Here's what we'll do: The inferred instruction properties will become tristate and default to Unset: bit hasSideEffects = ?; bit mayLoad = ?; bit mayStore = ?; TableGen will attempt to infer these properties from any instruction patterns. If inference fails and a property is unset, TableGen will issue an error instead of guessing. If inference succeeds and a property is set to an inconsistent value, TableGen...

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 convenient to use def : Pat<>, and sometimes custom instruction selection is required. As a result, many instructions are defined without a pattern, and we...

If an instruction is marked as side-effect free then it's a candidate for CSE. Try marking the instruction with hasSideEffects. Evan On Dec 17, 2011, at 12:24 PM, Johannes Birgmeier wrote: > Hello, > > I'm writing for a backend and have a complicated instruction bundle (3 > instructions) that has to be executed like a single block (meaning: if > the first instruction is executed, all three have to...

...sb, for example, can be implemented something like: inline void __isb() { __schedule_barrier_full(); __builtin_arm_isb(); __schedule_barrier_full(); } To implement these intrinsics, I think the best method is to add target-independent pseudo-instructions with appropriate properties(hasSideEffects for memory barrier and isTerminator for full barrier) and a pseudo-instruction elimination pass after the scheduling pass. What do people think of this idea? Cheers, Yi ------ [1] A piece of code that requires such behaviour is: Data_array[n] = x; // memory access __DSB(); __WFI();...

...correctly match it, but if I try to create some tablegen code that has no return value, the instruction gets deleted. Hi Micah, >From your description it sounds like machine dead code elimination is the most likely what's deleting your instruction. If that's the case, adding "let hasSideEffects = 1" to your instruction pattern should suffice to tell the compiler that there's more going on than it can detect just by looking at the inputs and outputs, and so it won't delete the instruction. Something like the following should do the trick: let hasSideEffects = 1 in def ATOM_G_...

...ackend (and backends in general I suppose) > > > > I can't speak directly to the questions themselves, but I'll ask a > couple back. When you say that some instructions are missing > mayLoad, do these instructions have patterns? Tablegen can infer > mayLoad/mayStores/hasSideEffects from patterns so it doesn't always > need to be listed explicitly in the td files. Having recently audited these flags in the PowerPC backend, I highly recommend looking at these from the *GenInstrInfo.inc file directly. I find this much easier. In theory, we'd like to move away from t...

...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 originally the intention that most instructions have patterns, but > that's not the way it worked out. It is often more convenient to use def : > Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are define...

Hi, we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag was incorrectly set while it actually shouldn't. The attached patch and test case triggers an assert in TwoAddress.  (bin/llc ./tc_TwoAddr_crash.ll -mtriple=s390x-linux-gnu -mcpu=z13) The only change in the patch is to remove the side effects flag from one instruction: -  def RISBMux...

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

Hi, So, I have inserted some calls to my intrinsic functions in a pass but there are being removed. The purpose of the intrinsics are to increment a specific register, the intrinsic call is lowered to a node that i have defined with SDNPSideEffect and the instruction also is defined as 'hasSideEffects = 1'. I have defined the instruction to return a i32 but take no arguments. Is there any way to stop my instruction being deleted or do I need to define my intrinsic as taking a register as an argument? And if this is the case, how do I define a target specific register as an argument to the c...