How to track down a bad llvm optimization pass
Dan Olson via digitalmars-d-ldc
digitalmars-d-ldc at puremagic.com
Mon Jun 20 08:46:20 PDT 2016
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
>>>> 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.
More information about the digitalmars-d-ldc