How to track down a bad llvm optimization pass

[Joakim via digitalmars-d-ldc]

On Friday, 17 June 2016 at 08:48:01 UTC, David Nadlinger wrote:
> 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.

Hmm, I had tried -print-after-all with --debug-pass=Executions 
before and those flags dumped so much info that I didn't go 
through it much.  Using -print-after-all alone is better: I see 
that the pass that muffs it up is "Global Value Numbering."  If I 
disable that pass in llvm's PassManagerBuilder, the problem goes 
away.

Looks like a regression in that llvm pass, I'll try building 
earlier versions of llvm to see if they had the same problem.

> 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.).

Given it works fine for other combinations of optimizations, I 
doubt it's a problem on our end, but I don't know enough about 
llvm's assumptions to say for certain.

On Friday, 17 June 2016 at 15:51:40 UTC, Dan Olson wrote:
> Joakim <dlang at joakim.fea.st> writes:
>
>> Since the update to ddmdfe 2.070, a single assert trips up on 
>> Android/ARM when running the druntime/phobos tests:
>>
>> https://github.com/dlang/phobos/blob/v2.070.2/std/conv.d#L5716
>
> Hi Joakim,
>
> Target arm-unknown-linux-gnueabihf is doing ok even with 
> v2.071.0 front end.  Isn't Android essentially the same, but 
> softfp?  Should be able to change triple and compare IR and see 
> what is different between android triple (what is it by the 
> way, arm-linux-android?) and gnueabihf triple. Or maybe it is 
> llvm version?  I've only been using 3.5 and 3.6.2 so far.

I get the same problem with that armhf triple and llvm 3.8.0, 
looks like it may be an llvm regression.

> I just tried both triples with ldc master of a week ago and 
> llvm-3.6.2. IR for each is identical except gnueabihf has stuff 
> for shared lib setup (dso_ctor, etc) which is not in android 
> version.

I'll try building and linking against llvm 3.6 and 3.7 and see if 
it makes a difference.