[llvm-commits] [llvm] r168930 - in /llvm/trunk: lib/Transforms/Scalar/CodeGenPrepare.cpp test/CodeGen/ARM/crash.ll

[Bill Wendling]

On Nov 29, 2012, at 12:28 PM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Bill,
> 
> On 29/11/12 20:38, Bill Wendling wrote:
>> Author: void
>> Date: Thu Nov 29 13:38:06 2012
>> New Revision: 168930
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=168930&view=rev
>> Log:
>> Handle the situation where CodeGenPrepare removes a reference to a BB that has
>> the last invoke instruction in the function. This also removes the last landing
>> pad in an function. This is fine, but with SjLj EH code, we've already placed a
>> bunch of code in the 'entry' block, which expects the landing pad to stick
>> around.
>> 
>> When we get to the situation where CGP has removed the last landing pad, go
>> ahead and nuke the SjLj instructions from the 'entry' block.
> 
> how do you know that the sjlj logic added this code?  Mightn't the user have
> placed calls to these guys themselves, eg by writing some IR by hand?  In which
> case they might be upset if you zap their code!

This is very specialized code. I highly doubt that anyone will be writing it by hand.

> Maybe the sjlj inserting pass
> should run after codegenprepare, not before.
> 
That's a possibility.

> At this point I should confess that I don't understand why codegenprepare is
> deleting dead basic blocks at all.  Shouldn't the IR optimizers have gotten
> them already?
> 

Good question. It's probably deleting dead blocks because it creates them and wants to clean up. And as far as this particular optimization, sure the optimizers could have gotten them already, but they didn't. And we still need to support this situation in the back-end (and not crash)...

I can explore moving the CGP before SjLj pass later...

-bw