similar to: GVN Hoist moving a store across load

Hello, I was trying a basic example on LLVM GVN Hoist and output differs from what I expect. Am I missing something ? *Code* : int main() { int x = 7; int a = 0; if(a == 7){ x = 1; a = 8 * x; } else { x = 1; a = 2 * x; } return 0; } *Commands* : clang-8 -O0 -S -emit-llvm test.c opt-8 -gvn-hoist -S < test.ll *Output :* ; ModuleID = '<stdin>' source_filename =

On 12/20/2017 1:37 PM, Sanjoy Das wrote:> > Fwiw, I was under the impression that regular loads could *not* be > reordered with volatile loads since we could have e.g.: > > int *normal = &global_variable; > volatile int* ptr = 0; > int k = *ptr; // segfaults, and the signal handler writes to *normal > int value = *normal; > > and that we'd have

The fact two IR values are defined the same way doesn't necessarily imply they are actually the same value. e.g. %a = load volatile i32, i32* %p %b = load volatile i32, i32* %p As Sanjoy said, though, it should always be legal to optimize all uses of different "freeze(%x)" values to use the same def - this is equivalent to choosing the same value for all freezes. It's just not

On 12/20/2017 03:49 PM, Alina Sbirlea via llvm-dev wrote: > +Philip to get his input too. > I've talked with George offline, and here's a summary: > > In D16875 <https://reviews.llvm.org/D16875>, the decision made was: > "The LLVM spec is ambiguous about whether we can hoist a non-volatile > load above a volatile load when the loads alias. It's probably

On 1/18/2013 11:11 AM, Dimitri Tcaciuc wrote: > > Right, I see. Is there any other way to solve this? As the last resort, > I was considering silently transforming each Array argument into > separate data and metadata arguments, but that would certainly add other > complications I'd rather avoid. Depends on what information you have available. If all you have is the LLVM IR,

On 7/30/2013 11:44 PM, Chris Lattner wrote: > > The canonical form should be that loop invariants are hoisted. The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common" properties of a loop, such as header, preheader, latch branch, etc. > Optimizations should not depend on perfect

I'd like to suggest a different direction which should accomplish similar ends. I think it would make sense to introduce an attribute: csecandidate. If we see a call-site "X" marked as csecandidate, it would imply that it can be replaced with any other call-site "Y" with the same arguments which dominate the call-site at "X". However, there are some cases that

I'm curious. Is there a specific technical reason that the high-level IR doesn't have an instruction to simply set a register to a constant? This limitation means we cannot hoist an "expensive" constant out of a loop until we lower the IR to MachineInstrs. Or more to the point, it forces backends to undo any such hoisting done by frontends. Or am I not understanding something?

On 1/18/2013 11:34 AM, Hal Finkel wrote: > > I agree. FWIW, I'm currently working on making the LLVM-based Fortran compiler non-hypothetical, and so for several reasons, I'd like to have a solution to this. If we can't think of anything better, we could always fall back to the N^2 metadata solution (explicit mark as no-alias all pairs that don't alias), but I'd rather we

Hi Krzysztof, Could I get some background info on reasoning about hoisting in the presence of volatile loads? I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll Context: MemorySSA treats volatile loads as defs. I'm looking to better understand expected behavior in the presence of volatile accesses. More context: https://reviews.llvm.org/D40375. Thanks in advance, Alina

On Jul 31, 2013, at 6:53 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/30/2013 11:44 PM, Chris Lattner wrote: >> >> The canonical form should be that loop invariants are hoisted. > > The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common"

Hi everyone, The MachineLICM pass has a heuristic such that, even in low-register-pressure situations, it will refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides this more-customized definition: bool ARMBaseInstrInfo::

On 1/17/2013 11:33 PM, Owen Anderson wrote: > > Almost certainly, the compiler can't tell that the load from the struct > (to get the array pointer) doesn't alias with the stores to the array > itself. This is exactly the kind of thing that type-based alias > analysis (-fstrict-aliasing) can help with. Use with caution, as it > can break some type-unsafe idioms. The

Hello LLVM, To reduce the code-size cost of relocations, I'm trying to hoist GlobalValues that are used many times. A new pass hides each hoisted GV behind a BITCAST in the dominating BB. The pass then updates users with the output of the BITCAST. This pass works properly AFAICT. The problems come in instruction selection. SelectionDAGBuilder::visitBitCast() treats the BITCAST as a no-op

On Fri, Jan 18, 2013 at 10:00 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > f90_array_type = type { i32 size, double* data }; I am not certain how fortran implements multi-dimensional arrays, but in my case I'm doing something like type { i32 nd, i32* dims, double* data }; Perhaps we could add !tbaa.pointer? !1 = metadata !{ metadata !"int",

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group

and by "right thing" i mean it can hoist if you want and it can prove it will not extend the live range. Note that VBE (very busy expressions) is a code size optimization only. It does not save time. On Tue, Feb 9, 2016 at 12:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > This GVN does not do that, this is correct. It is a very simple GVN. All > phi nodes are

Samuel Crow wrote: >> From: Andre Tavares <andrelct at dcc.ufmg.br> >> I'm working on a project to remove unnecessary array bound checks in >> Java. For this purpose I will need to use llvm-java. >> >> What is the state of llvm-java? Can someone explain how to build and use it? >> >> I saw some old emails on the list, and some about a SoC 2008

Does LLVM hoist bounds checks out of inner loops? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

Hi, I've recently run into a problem of missing !dbg metadata after the code has been optimized (even opt -O1). The original code was generated using llvmlite python package and I've verified that all instructions have their !dbg metadata present. After optimizing the module (even opt -O1) I see that some instructions (~25%) don't have any dbg metadata. These are mostly getelementptr