How to track down a bad llvm optimization pass

[David Nadlinger via digitalmars-d-ldc]

On 17 Jun 2016, at 0:23, Joakim via digitalmars-d-ldc wrote:
> Why including the first assert combines with some optimization pass 
> and inlining to produce this junk instruction instead, I don't know.  
> I don't think this is something that needs to be fixed on the ldc end, 
> but who knows.  Anyone have any tips on tracking this down?

Without having looked at the details of what's going on here in 
particular, my first step would be to use the "-print-after-all" option 
and look where the part that you think is clearly wrong first appears 
(e.g. just by textual search). Having a look at what the input to that 
pass was (i.e. the previous pass result) can often yield extra insight.

bugpoint, the LLVM tool for reducing test cases, also has some 
functionality to reduce the set of passes needed to trigger a 
miscompilation. It has worked for me in the past, but I always found 
configuring the linking/executing step to be a bit finicky.

As a general comment, it is of course possible that we are hitting a 
genuine LLVM bug here, but I'd also be on the lookout for cases where we 
might be generating invalid IR (in the sense that we trigger some 
documented undefined behaviour, violate some assumptions, etc.).

  — David