<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In our (non-C) compiler we use setjmp/longjmp to implement exception<br>
handling. For the initial implementation LLVM backend, I'm keeping that<br>
model. In order to ensure that changes performed in a try/setjmp==0<br>
block survive the longjmp, the changes must be done via volatile operations.<br></blockquote><div><br></div><div>If you want to observe those volatile store updates, you're really going to need to volatilize the load operations. In your example, LLVM does not model the CFG edge from the longjmp to the setjmp. This leads LLVM to conclude that the only reaching definition of 'loops' at the point of the load in the else block is 'loops = 0'.</div><div><br></div>Volatilizing all operations on local variables is going to kill your performance, obviously. You should really emit invoke instructions in your frontend. You can either use your own EH personality, or the existing SjLj EH personality, which will optimize on a correct CFG and then volatilize all values live across exceptional edges. Then the LLVM CFG will be correct, and you'll get pretty good code.</div></div></div>