search for: guessinstructionproperti

...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 the pattern-based flag inference. Once a target is free of dependence on the inference rules, it can set bit guessInstructionProperties = 0; to turn them off completely (see class InstrInfo in Target.td). > > In MHO, we should try to avoid redundancy as much as possible. The only reason to have these flags is when instructions don't have patterns. I'm fairly certain that Jakob put in an error (warning?) when tabl...

...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 the pattern-based flag inference. Once a target is free of dependence on the inference rules, it can set bit guessInstructionProperties = 0; to turn them off completely (see class InstrInfo in Target.td). >>> >>> In MHO, we should try to avoid redundancy as much as possible. The only reason to have these flags is when instructions don't have patterns. >> >> I'm fairly certain that Jakob pu...

...sult 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 causes an error <https://reviews.llvm.org/rL162460> if a property isn't set explicitly and can't be inferred. It doesn't look like any other in-tree targets have ended up enabling this, but it looks like it would be worth enabling for RISCV, particularly if going ahe...

...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 the pattern-based flag inference. Once a target is free of dependence on the inference rules, it can set bit guessInstructionProperties = 0; to turn them off completely (see class InstrInfo in Target.td). -Hal > > > Instructions without patterns are marked hasSideEffects=1 which is > more restrictive than mayLoad/mayStore. > > > > On Mon, Dec 30, 2013 at 1:56 PM, Chandler Carruth < > chandler...

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

Hi Jonas, Thanks for bringing that up. > On Nov 30, 2017, at 4:04 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 -mtri...

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

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