llvm dev - Nov 2015 - DFAPacketizer assert failure

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>

Watching from the sidelines but I'm curious too.  In an ideal world codegen
is independent of –g but CFI-as-instructions makes that hard. Even on non-VLIW
like X86 we see instruction-scheduling differences depending on whether CFI
instructions are present. All cases we've seen so far are innocuous but
having differences at all makes it hard to write must-be-identical kinds of
tests.
Thanks,
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Rail
Shafigulin via llvm-dev
Sent: Thursday, November 19, 2015 4:55 PM
To: Krzysztof Parzyszek
Cc: llvm-dev
Subject: Re: [llvm-dev] DFAPacketizer assert failure



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/20151120/fea0b31b/attachment-0001.html>

On 11/20/2015 1:24 AM, Robinson, Paul wrote:
> Watching from the sidelines but I'm curious too.  In an ideal world
> codegen is independent of –g but CFI-as-instructions makes that hard.
> Even on non-VLIW like X86 we see instruction-scheduling differences
> depending on whether CFI instructions are present. All cases we've seen
> so far are innocuous but having differences at all makes it hard to
> write must-be-identical kinds of tests.
>
I have a small pass that does that after everything else has been done.

Look in lib/Target/Hexagon/HexagonFrameLowering.cpp, the class name is 
HexagonCallFrameInformation.

Then in lib/Target/Hexagon/HexagonTargetMachine.cpp, we do:

void HexagonPassConfig::addPreEmitPass() {
   [...]
   // Add CFI instructions if necessary.
   addPass(createHexagonCallFrameInformation(), false);
}


-Krzysztof


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