On Sunday, 19 June 2016 at 06:45:42 UTC, Dan Olson wrote:
> Dan Olson <gorox@comcast.net> writes:
>
>> Joakim <dlang@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?

On 19 Jun 2016, at 7:58, Joakim via digitalmars-d-ldc wrote:
> Anyone know if we're breaking some llvm assumptions here?

I'm not aware of any – if that is the case (which is quite likely), then it's of course a bug in our code gen.

What I'd be inclined to do is to have a manual look at the IR immediately before GVN and see whether there is anything fishy to spot there already. I might also use a debugger on GVN to see exactly why it thinks it can perform a certain replacement – the LLVM pass internals are usually fairly well documented, although GVN is of course algorithmically a bit cumbersome to trace.

 — David

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

> On Sunday, 19 June 2016 at 06:45:42 UTC, Dan Olson wrote:
>> Dan Olson <gorox@comcast.net> writes:
>>
>>> Joakim <dlang@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

On 19.06.2016 08:58, Joakim wrote:
> On Sunday, 19 June 2016 at 06:45:42 UTC, Dan Olson wrote:
>> Dan Olson <gorox@comcast.net> writes:
>>
>>> Joakim <dlang@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.

On Monday, 20 June 2016 at 20:15:52 UTC, Rainer Schuetze wrote:
>
>
> On 19.06.2016 08:58, Joakim wrote:
>> On Sunday, 19 June 2016 at 06:45:42 UTC, Dan Olson wrote:
>>> Dan Olson <gorox@comcast.net> writes:
>>>
>>>> Joakim <dlang@joakim.fea.st> writes:
>>>>
>>>>> [...]
>>>>
>>>> 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.

OK, will do.  I think the fact that the exact same ldc frontend linked with llvm 3.7.1 doesn't have this problem, only when linked against llvm 3.8.0, indicates this most likely isn't a problem on our end.

On Tuesday, 21 June 2016 at 05:51:56 UTC, Joakim wrote:
> On Monday, 20 June 2016 at 20:15:52 UTC, Rainer Schuetze wrote:
>>
>>
>> On 19.06.2016 08:58, Joakim wrote:
>>> [...]
>>
>> 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.
>
> OK, will do.  I think the fact that the exact same ldc frontend linked with llvm 3.7.1 doesn't have this problem, only when linked against llvm 3.8.0, indicates this most likely isn't a problem on our end.

Filed: https://llvm.org/bugs/show_bug.cgi?id=28224

On Tuesday, 21 June 2016 at 07:00:35 UTC, Joakim wrote:
> On Tuesday, 21 June 2016 at 05:51:56 UTC, Joakim wrote:
>> On Monday, 20 June 2016 at 20:15:52 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 19.06.2016 08:58, Joakim wrote:
>>>> [...]
>>>
>>> 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.
>>
>> OK, will do.  I think the fact that the exact same ldc frontend linked with llvm 3.7.1 doesn't have this problem, only when linked against llvm 3.8.0, indicates this most likely isn't a problem on our end.
>
> Filed: https://llvm.org/bugs/show_bug.cgi?id=28224

Hmmm.  I looked at failing code in std.conv.  I think it does a negative shift, which is undefined in C.  It is the opSlice() method.

On Tuesday, 21 June 2016 at 19:41:59 UTC, Dan Olson wrote:
> Hmmm.  I looked at failing code in std.conv.  I think it does a negative shift, which is undefined in C.  It is the opSlice() method.

Or rather with unsigned types, a really big shift, also undefined.

Dan Olson <gorox@concast.net> writes:

> On Tuesday, 21 June 2016 at 19:41:59 UTC, Dan Olson wrote:
>> Hmmm.  I looked at failing code in std.conv.  I think it does a negative shift, which is undefined in C.  It is the opSlice() method.
>
> Or rather with unsigned types, a really big shift, also undefined.

std.conv.toChars() just has a bug and LLVM 3.8 is behaving ok with an undefined operation.  The unittest for toChars isn't very exhaustive for opSlice and gets lucky on Intel targets.  LDC with LLVM 3.5 also gets lucky on the limited unittest but toChars() clearly gives wrong results with better test case.

Simple fix, following line should not have `- 1`:

https://github.com/ldc-developers/phobos/blob/ldc/std/conv.d#L5700

I fixed locally and std.conv unittest is happy now.  I will run full test suite on arm to make doubly sure, but I think this will end up as a phobos bug and PR.
-- 
Dan

Dan Olson <gorox@comcast.net> writes:

> Dan Olson <gorox@concast.net> writes:
>
>> On Tuesday, 21 June 2016 at 19:41:59 UTC, Dan Olson wrote:
>>> Hmmm.  I looked at failing code in std.conv.  I think it does a negative shift, which is undefined in C.  It is the opSlice() method.
>>
>> Or rather with unsigned types, a really big shift, also undefined.
>
> std.conv.toChars() just has a bug and LLVM 3.8 is behaving ok with an undefined operation.  The unittest for toChars isn't very exhaustive for opSlice and gets lucky on Intel targets.  LDC with LLVM 3.5 also gets lucky on the limited unittest but toChars() clearly gives wrong results with better test case.
>
> Simple fix, following line should not have `- 1`:
>
> https://github.com/ldc-developers/phobos/blob/ldc/std/conv.d#L5700
>
> I fixed locally and std.conv unittest is happy now.  I will run full test suite on arm to make doubly sure, but I think this will end up as a phobos bug and PR.

Testsuite passes with LLVM 3.8.0 now.  Filed phobos bug:

https://issues.dlang.org/show_bug.cgi?id=16192

Should probably make an LDC Issue to track and pick phobos fix.