r246985 - Compute and preserve alignment more faithfully in IR-generation.

[Chandler Carruth via cfe-commits]

On Thu, Sep 10, 2015 at 7:27 PM John McCall <rjmccall at apple.com> wrote:

> On Sep 10, 2015, at 16:09, Chandler Carruth <chandlerc at google.com> wrote:
>
>
> On Thu, Sep 10, 2015 at 3:26 PM John McCall <rjmccall at apple.com> wrote:
>
>> On Sep 10, 2015, at 3:22 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>
>> I've reproduced this with the same technique.
>>
>> John, let me know if you need help debugging this, but this is blocking a
>> ton of stuff for us so I'm going to revert for now.
>>
>>
>> Please just give me a chance to fix; it is probably straightforward, and
>> the change is invasive enough that you’ll have to revert the last three
>> days of changes to IRGen.
>>
>
> I mean, I'd love to avoid the revert, but were totally hosed at the moment
> by this change (perhaps our fault for so much code managing to use a silly
> jpeg library). I'm going to at least start working on teasing this stuff
> apart in parallel, and hopefully you'll have a fix soon. While we're going
> to need to revert to green before too long, I'll update here before doing
> anything. Also happy to chat on IRC if there is anything I can do to help.
>
>
> For those following along at home, we tracked this down to some assembly
> that's not following the x86-64 ABI correctly.
>
> Clang is emitting a pair of adjacent 32-bit loads. With my patch, the
> first is now marked with alignment 8; LLVM deduces that the loads can be
> combined. Later, the first value is passed as an argument to a function,
> and LLVM places the combined load in the argument register without clearing
> the high bits; this is legal as those bits have no guaranteed value under
> the ABI. The callee, which is written in assembly, then uses the full
> register as an index into an array without zero-extending it first.
>

Another note is that I'm going to keep an eye out for any other assembly we
run into making similar assumptions, but after digging into the project, it
appears that most of this is likely a historical error for a single type.

And I just want to say *many* thanks for the assistance understanding this
error John (and David, Art, Richard, and everyone else)... It was not at
all easy to really pinpoint the nature of this problem, and made more
confusing by the fact that the ABI seems silent about this (despite the
clear behavior of multiple implementations).

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150911/0494b551/attachment-0001.html>