search for: safe_cast

...is constant and unchanging.". I think this implies that if the result of an `llvm.invariant.start` doesn't escape, we can safely conclude that there can be no matching `llvm.invariant.end`. I'm still a little hazy on all of the use cases you want to support, but one problem with llvm.safe_cast is, as you note, stores to the pointer passed to safe_cast will not be forwarded to loads from the pointer it returns. I think this issue can be solved by modeling `llvm.safe_cast` not as a transformation on a pointer, but as a check. Specifically, I imagine a readonly intrinsic `llvm.assert_immut...

On 09/28/2014 01:22 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Philip Reames" <listmail at philipreames.com> >> To: llvmdev at cs.uiuc.edu >> Cc: "Hal Finkel" <hfinkel at anl.gov>, nicholas at mxc.ca >> Sent: Wednesday, September 10, 2014 12:11:28 AM >> Subject: Optimization hints for "constant" loads

...on is not invariant) and the rest of the execution (where the location is invariant). This approach looks similar to Ruby's "freeze" method: http://ruby-doc.org/core-2.1.3/Object.html#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 mat...

...where the location is invariant). >> >> This approach looks similar to Ruby's "freeze" method: >> http://ruby-doc.org/core-2.1.3/Object.html#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...

> That said, many dynamic languages should be cleanly mappable to the LLVM > layer. What are you thinking about in particular? Not thinking of one in particular right now, but it would probably something like an object-oriented Scheme. > recommend writing some language tuned optimizations (as necessary) that > would lower the dynamic objects into the primitives the optimizers >