llvm dev - Nov 2015 - Hexagon and choosing of slots

I'm curious how does hexagon hardware decide which slot to use for a given
instruction? Is there special hardware to make that decision? I'm asking
because I didn't see any information about which slot to use for a given
packet. Is it even possible to pass this kind of information through
assembly? Say hardware sees a packet and the packet tells it which slot to
use.

I would greatly appreciate any comments on this.

-- 
R
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151123/f013c982/attachment.html>

On 11/23/2015 12:26 PM, Rail Shafigulin via llvm-dev
wrote:
> I'm curious how does hexagon hardware decide which slot to use for a
> given instruction? Is there special hardware to make that decision? I'm
> asking because I didn't see any information about which slot to use for
> a given packet. Is it even possible to pass this kind of information
> through assembly? Say hardware sees a packet and the packet tells it
> which slot to use.
On Hexagon, the slot assignment is determined by the layout of the 
instructions in memory.  The order of the instructions in the packet 
does not matter either in the IR, nor in the .s file, but it does when 
the packet is encoded into the actual machine code.  In LLVM, the 
Hexagon shuffler orders the instructions just prior to encoding.

Specifically, the instructions in the packet are encoded "in reverse",
i.e. the instruction that will go to the highest slot will be encoded 
first, then the instruction that will go to the second highest slot, 
etc.  In case of a packet with 4 instructions, it will be
   addr:    slot3
   addr+4:  slot2
   addr+8:  slot1
   addr+12: slot0
Not all slots have to be occupied. If they are not, the hardware will 
assign the slots based on the instruction, but within a packet the slots 
must be in a decreasing order.  For example:
   addr:    slot2
   addr+4:  slot0
is ok, but
   addr:    slot1
   addr+4:  slot0
is not.

There are also bits in each encoding word that indicate the end of the 
packet: those must also be set properly by the compiler.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On 11/23/2015 1:02 PM, Krzysztof Parzyszek via llvm-dev
wrote:
> [...] but
>    addr:    slot1
>    addr+4:  slot0
> is not.
>
Error. ^This one is actually ok, I meant:

addr:   slot0
addr+4: slot1

The hardware will verify that a given instruction may actually execute 
in a given slot, and if not, it will generate an exception.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

> On Hexagon, the slot assignment is determined by the layout of the
> instructions in memory.  The order of the instructions in the packet does
> not matter either in the IR, nor in the .s file, but it does when the
> packet is encoded into the actual machine code.  In LLVM, the Hexagon
> shuffler orders the instructions just prior to encoding.
>
> Specifically, the instructions in the packet are encoded "in
reverse",
> i.e. the instruction that will go to the highest slot will be encoded
> first, then the instruction that will go to the second highest slot, etc.
> In case of a packet with 4 instructions, it will be
>   addr:    slot3
>   addr+4:  slot2
>   addr+8:  slot1
>   addr+12: slot0
> Not all slots have to be occupied. If they are not, the hardware will
> assign the slots based on the instruction, but within a packet the slots
> must be in a decreasing order.  For example:
>   addr:    slot2
>   addr+4:  slot0
> is ok, but
>   addr:    slot1
>   addr+4:  slot0
> is not.
>
> There are also bits in each encoding word that indicate the end of the
> packet: those must also be set properly by the compiler.
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
Would you mind pointing me to the source code where actual shuffling
occurs. I looked through lib/Target/Hexagon but was not able to find it. Is
shuffling now part of a core code?

Thanks,

-- 
R
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151124/879853cf/attachment.html>