[PATCH] Long NOP padding

[David Sehr]

Largely because it was that way before I tweaked it :-)  I have updated to
use uint8_t below.

David


On Mon, Mar 4, 2013 at 2:13 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:

>  Hi David,
>
> +  // 15 is the longest single nop instruction.  Emit as many 15-byte nops
> as
> +  // needed, then emit a nop of the remaining length.
> +  do {
> +    uint64_t ThisNopLength = std::min(Count, (uint64_t) 15);
> +    const uint64_t Prefixes = ThisNopLength <= 10 ? 0 : ThisNopLength -
> 10;
> +    for (uint64_t i = 0; i < Prefixes; i++)
> +      OW->Write8(0x66);
>
> Why are the types 64bit ? Looks like a shorter type would suffice here,
> short/unsigned char ?
>
> Thanks
>
> Shankar Easwaran
>
>
> On 3/4/2013 4:06 PM, David Sehr wrote:
>
> The current X86 NOP padding uses one long NOP followed by the remainder in
> one-byte NOPs.  If the processor actually executes those NOPs, as it
> sometimes does with aligned bundling, this can have a performance impact.
>  From my micro-benchmarks run on my one machine, a 15-byte NOP followed by
> twelve one-byte NOPs is about 20% worse than a 15 followed by a 12.  This
> patch changes NOP emission to emit as many 15-byte (the maximum) as
> possible followed by at most one shorter NOP.
>
> David
>
>
>
>
> _______________________________________________
> llvm-commits mailing listllvm-commits at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130304/e679b8d4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: longnop.patch
Type: application/octet-stream
Size: 2441 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130304/e679b8d4/attachment.obj>