[llvm] r336178 - [ADT] Disable the single callback optimization on Windows.

[Chandler Carruth via llvm-commits]

On Tue, Jul 3, 2018 at 1:05 PM Friedman, Eli <efriedma at codeaurora.org>
wrote:

> On 7/3/2018 1:19 AM, Chandler Carruth via llvm-commits wrote:
> > Author: chandlerc
> > Date: Tue Jul  3 01:19:10 2018
> > New Revision: 336178
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=336178&view=rev
> > Log:
> > [ADT] Disable the single callback optimization on Windows.
> >
> > It appears that the function pointer we use there isn't reliably 4-byte
> > aligned. I have no idea why or how we could correct this, so for now we
> > just regress the Windows performance some.
>
> I don't know why you'd expect functions to be aligned; x86 doesn't
> require any alignment. clang usually prefers to align functions to 16
> bytes because the instruction decoder fetches 16 bytes at a time, but it
> won't align the entry point at all at -Oz.


I thought there was at least some ABI requirements, but I'm happy to add an
explicit alignment attribute which should be sufficient outside of Windows?


> And even on platforms where
> functions are aligned, function pointers might not be aligned; for
> example, ARM uses the bottom bit for interworking.
>

Yes, but I think we can just insist "don't use such function pointers here"?

I understand that we can't get a fully general thing, but given that we
control both the function definition and the use of the address, it seems
reasonable to try quite hard to get the aligned pointer. This seems
especially true given that there will always be *many* empty bits in a
function pointer.

I really don't want to use separate storage for the flag because that will
use not one byte, but in practice 8 bytes.

I really don't want to use a double indirection because of the performance
hit.

I'm happy to fallback on double indirection when we don't have a reasonably
compliant ABI / compiler though.

Does that make sense? (Hans already sent the patch w/ the explicit
alignment attribute...)


> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180703/14f8e4f7/attachment.html>