How to track down a bad llvm optimization pass

[Dan Olson via digitalmars-d-ldc]

Joakim <dlang at joakim.fea.st> writes:

> 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?

Most times when I found an llvm "bug", it turned out clang was
generating slightly different IR than LDC.  An example is using "byval"
only for aggregates > 64-bytes.  Only way to know these rules is looking
at clang source.  Currently, LDC abi-arm.cpp isn't following all rules
that clang uses.  My hunch is there is another.
-- 
Dan