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

[Friedman, Eli via llvm-commits]

On 7/3/2018 1:25 PM, Chandler Carruth wrote:
> On Tue, Jul 3, 2018 at 1:05 PM Friedman, Eli <efriedma at codeaurora.org 
> <mailto: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?

The alignment attribute should work on most targets, yes... but it won't 
work on ARM or certain MIPS variants.

>     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 would guess most users of LLVM on ARM use Thumb2, since it's smaller 
(and therefore faster). So functions pointers will generally have the 
least significant bit set.  But we can work around that with some 
target-specific hacks if we control the callee.

Not sure about the details for MIPS.

-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/bb8b0565/attachment.html>