search for: check_cast

...method-i-freeze What is the aliasing relationship between a non-invariant load from the result of a safe_cast and a load from (or store to) the argument we pass to it? Is it sensible to make them MustAlias? I'm trying to think if a frontend needs to be careful about using the return value of check_cast only for !invariant loads (or some other restriction), or is it legal (or desirable) to mix and match both kinds of loads from both kinds of pointers. -- Sanjoy

...g relationship between a non-invariant load from >> the result of a safe_cast and a load from (or store to) the argument >> we pass to it? Is it sensible to make them MustAlias? I'm trying to >> think if a frontend needs to be careful about using the return value >> of check_cast only for !invariant loads (or some other restriction), >> or is it legal (or desirable) to mix and match both kinds of loads >> from both kinds of pointers. > %p1 = ... > store %v0, %p1 > %p2 = llvm.safe_cast %p1 > store %v1, %p1 > store %v2, %p2 > %v3 = load %p2, !inv...

> I've never realy understood how the llvm.invariant intrinsics could be > put into practice. There is the problem that "end" can occur anywhere > as you suggested fixing with a flag. I was under this impression too, but after re-reading the language reference I'm not so sure -- it says about invariant.start: "This intrinsic indicates that until an