[llvm-dev] DFAPacketizer assert failure

[Robinson, Paul via llvm-dev]

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>