On Tue, Apr 15, 2014 at 2:14 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:> I've looked through LLVM codegen code and found that > SelectionDAGBuilder::visitUnreachable() is basically a no-op. So I don't > see how it could have generated anything... > > What would be the right way to go about adding this functionality? > Right now I am thinking to add 'EmitTargetCodeForUnreachable()' method to > TargetSelectionDAGInfo class, so that targets can emit code for > 'unreachable', if they need that. Does that sound right? >Personally I'm in favor, but others may disagree. Right now clang inserts calls to llvm.trap(), and that's how we get ud2's when falling off the end of a function with a return type. That may be the preferred approach for __builtin_unreachable(), since other clients of LLVM at -O0 may actually want it to produce code quickly without inserting any debugging aids. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/57546086/attachment.html>
On 15 Apr 2014, at 22:22, Reid Kleckner <rnk at google.com> wrote:> Personally I'm in favor, but others may disagree. Right now clang inserts calls to llvm.trap(), and that's how we get ud2's when falling off the end of a function with a return type. That may be the preferred approach for __builtin_unreachable(), since other clients of LLVM at -O0 may actually want it to produce code quickly without inserting any debugging aids.It would be trivial to write a pre-codegen pass that would turn all unreachable instructions into calls to llvm.trap and then unreachable. If a front end wants to guarantee a trap, then it is also free to insert the trap (and it will be deleted later if the basic block becomes truly unreachable). I'd be somewhat hesitant about making it the default behaviour, because machine instruction passes may want to do some reordering of instructions and once they've got an instruction that is guaranteed to trap then it enforces hard constraints on flow control. To preserve this, you'd need to keep it as a pseudo right up until the very last stage of compilation, which adds some complexity to back ends. David
Created patch in Phabricator with Vadim patch from the other thread. http://reviews.llvm.org/D3417 2014-04-17 11:26 GMT+03:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:> On 15 Apr 2014, at 22:22, Reid Kleckner <rnk at google.com> wrote: > > > Personally I'm in favor, but others may disagree. Right now clang > inserts calls to llvm.trap(), and that's how we get ud2's when falling off > the end of a function with a return type. That may be the preferred > approach for __builtin_unreachable(), since other clients of LLVM at -O0 > may actually want it to produce code quickly without inserting any > debugging aids. > > It would be trivial to write a pre-codegen pass that would turn all > unreachable instructions into calls to llvm.trap and then unreachable. If > a front end wants to guarantee a trap, then it is also free to insert the > trap (and it will be deleted later if the basic block becomes truly > unreachable). > > I'd be somewhat hesitant about making it the default behaviour, because > machine instruction passes may want to do some reordering of instructions > and once they've got an instruction that is guaranteed to trap then it > enforces hard constraints on flow control. To preserve this, you'd need to > keep it as a pseudo right up until the very last stage of compilation, > which adds some complexity to back ends. > > David > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140418/788b254a/attachment.html>