llvm dev - Nov 2015 - DFAPacketizer assert failure

> Does the instruction that is being added have an itinerary associated with
> it?
>
So I checked again, and it turns out that it does have an itinerary
associated with it. However it is a pseudo instruction. Does the packetizer
do something special with the pseudo instructions? I didn't see any special
code, but I could have missed it.

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

On 11/16/2015 3:49 PM, Rail Shafigulin wrote:
>
>     Does the instruction that is being added have an itinerary
>     associated with it?
>
> So I checked again, and it turns out that it does have an itinerary
> associated with it. However it is a pseudo instruction. Does the
> packetizer do something special with the pseudo instructions? I didn't
> see any special code, but I could have missed it.
The packetizer should not do anything with these---they should not be 
inserted into a bundle.  I'm not sure if the code in DFAPacketizer.cpp 
does that or not.  In the Hexagon backend we originally treated CFI 
instructions as "solo", i.e. they could not be packetized with any
other
instruction.  Now we simply delay the generation of these instructions 
until after packetization.  The reason for this is that two instructions 
that could be packetized together were not packetized together if there 
was an CFI instruction in between.  This was causing different code to 
be generated with the CFI instructions present.

In general, most pseudo instructions should have been expanded into real 
instructions by the time the packetizer runs. For exeptional cases, you 
can treat them as not being packetizable with any other instructions.

-Krzysztof

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

On Mon, Nov 16, 2015 at 2:29 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 11/16/2015 3:49 PM, Rail Shafigulin wrote:
>
>>
>>     Does the instruction that is being added have an itinerary
>>     associated with it?
>>
>> So I checked again, and it turns out that it does have an itinerary
>> associated with it. However it is a pseudo instruction. Does the
>> packetizer do something special with the pseudo instructions? I
didn't
>> see any special code, but I could have missed it.
>>
>
> The packetizer should not do anything with these---they should not be
> inserted into a bundle.  I'm not sure if the code in DFAPacketizer.cpp
does
> that or not.  In the Hexagon backend we originally treated CFI instructions
> as "solo", i.e. they could not be packetized with any other
instruction.
> Now we simply delay the generation of these instructions until after
> packetization.  The reason for this is that two instructions that could be
> packetized together were not packetized together if there was an CFI
> instruction in between.  This was causing different code to be generated
> with the CFI instructions present.
>
> In general, most pseudo instructions should have been expanded into real
> instructions by the time the packetizer runs. For exeptional cases, you can
> treat them as not being packetizable with any other instructions.
>
>
> -Krzysztof
>
> --
>
Thanks for the explanation.

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

In the Hexagon backend we originally treated CFI instructions as
"solo",
> i.e. they could not be packetized with any other instruction.  Now we
> simply delay the generation of these instructions until after
> packetization.  The reason for this is that two instructions that could be
> packetized together were not packetized together if there was an CFI
> instruction in between.  This was causing different code to be generated
> with the CFI instructions present.

How do you delay the generation of the CFI instructions? I'm having the
same problem as you had. They really mess up my packets. I'd really
appreciate if you could point me to the code that shows where delayed
generation of CFI instructions occurs.

Thanks,

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