How to track down a bad llvm optimization pass

[Rainer Schuetze via digitalmars-d-ldc]

On 19.06.2016 08:58, Joakim wrote:
> On Sunday, 19 June 2016 at 06:45:42 UTC, Dan Olson wrote:
>> Dan Olson <gorox at comcast.net> writes:
>>
>>> Joakim <dlang at joakim.fea.st> writes:
>>>
>>>> On Saturday, 18 June 2016 at 15:31:03 UTC, Joakim wrote:
>>>> I just built and linked against llvm 3.7.1 and the problem goes away,
>>>> so it appears that it is a regression in the GVN optimization pass
>>>> with llvm 3.8.0.  I'll check if it goes away with llvm master, and
>>>> file an llvm bug if it doesn't.
>>>
>>> And I am trying opposite: builting ldc master against llvm 3.8.0.
>>> See if I can duplicate the problem.
>>
>> Yup, fails same way on a Raspberry Pi with 3.8.0.
>
> And it's still hitting on llvm 3.9 master svn-271934 from a couple weeks
> ago, looks like we'll have to submit a bug report.  Anyone know if we're
> breaking some llvm assumptions here?

If it fails in a specific optimization pass, it has already passed a 
number of verification passes. When I posted some bug reports, the LLVM 
people (who have been very helpful) considered it an LLVM bug if an 
invalid IR passes the verifier. So even if some assumptions are broken, 
I would suggest to report to the LLVM bug tracker.