search for: widden

In my language there are a lot of i16 definitions, but almost all of the time they are upgraded to i32 because my add operations only happen on i32. So to be representative to my language definition, I have a lots of Sext/Zext and Truncs pretty much every time I add or subtract. As soon as I pass through InstCombine things look much nicer, all the upcasts and downcasts go away, but my test cases

...` will apply to `@llvm.exception_on`. > > Not sure we actually need this. A valid implementation of the side exit > handler (which would do the OSR for us) is to call a runtime routine which > generates and throws the exception. The only bit we might need is a > distinction between widdenable and non-widenable guards. Yes, and that's the only distinction I'm trying to make here. >> ## memory effects (unresolved) >> >> [I haven't come up with a good model for the memory effects of >> `@llvm.guard_on`, suggestions are very welcome.] >> &gt...

This is a proposal to add guard intrinsics to LLVM. Couple of glossary items: when I say "interpreter" I mean "the most conservative tier in the compilation stack" which can be an actual interpreter, a "splat compiler" or even a regular JIT that doesn't make optimistic assumptions. By "bailing out to the interpreter" I mean "side exit" as