llvm dev - Dec 2017 - DBG_VALUE insertion for spills breaks bundles

Hi,

The insertion of DBG_VALUE instructions for spills does not seem to be handling
insert locations inside bundles well. If the spill instruction is part of a
bundle, the new DBG_VALUE is inserted after it, but does not have the bundling
flags set. This essentially means that if we start with a set of bundled
instructions:

MI1 [BundledSucc=true,  BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]

Where MI1 is a spill, and MI2 is a different instruction, after ExtendRanges we
end up with

MI1 [BundledSucc=true,  BundledPred=false]
DBG_VALUE MI [BundledSucc=false,  BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]

Since this happens after the final instruction scheduling, it results in broken
schedules. I believe setting the bundling flags before invoking
MBB->insertAfter in ExtendRanges should fix this.

Best regards
Saurabh Verma
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171219/70314b80/attachment.html>

Hi again,

Here is a small patch to fix this issue.  Please note that since the problem
results in broken bundles, it can result in invalid schedules for any VLIW
back-ends using bundling to group instructions.

Best regards
Saurabh Verma

From: Verma, Saurabh
Sent: Tuesday, December 19, 2017 4:14 PM
To: llvm-dev at lists.llvm.org
Subject: DBG_VALUE insertion for spills breaks bundles

Hi,

The insertion of DBG_VALUE instructions for spills does not seem to be handling
insert locations inside bundles well. If the spill instruction is part of a
bundle, the new DBG_VALUE is inserted after it, but does not have the bundling
flags set. This essentially means that if we start with a set of bundled
instructions:

MI1 [BundledSucc=true,  BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]

Where MI1 is a spill, and MI2 is a different instruction, after ExtendRanges we
end up with

MI1 [BundledSucc=true,  BundledPred=false]
DBG_VALUE MI [BundledSucc=false,  BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]

Since this happens after the final instruction scheduling, it results in broken
schedules. I believe setting the bundling flags before invoking
MBB->insertAfter in ExtendRanges should fix this.

Best regards
Saurabh Verma
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171222/3877b2ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbg_value_fix.patch
Type: application/octet-stream
Size: 1066 bytes
Desc: dbg_value_fix.patch
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171222/3877b2ef/attachment.obj>

Thank you for your patch. Could you please add a testcase to it and upload it to
reviews.llvm.org and CC llvm-commits, me and the debug-info group?

-- adrian
> On Dec 22, 2017, at 6:28 AM, Verma, Saurabh via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi again,
>  
> Here is a small patch to fix this issue.  Please note that since the
problem results in broken bundles, it can result in invalid schedules for any
VLIW back-ends using bundling to group instructions.
>  
> Best regards
> Saurabh Verma
>  
> From: Verma, Saurabh 
> Sent: Tuesday, December 19, 2017 4:14 PM
> To: llvm-dev at lists.llvm.org
> Subject: DBG_VALUE insertion for spills breaks bundles
>  
> Hi,
>  
> The insertion of DBG_VALUE instructions for spills does not seem to be
handling insert locations inside bundles well. If the spill instruction is part
of a bundle, the new DBG_VALUE is inserted after it, but does not have the
bundling flags set. This essentially means that if we start with a set of
bundled instructions:
>  
> MI1 [BundledSucc=true,  BundledPred=false]
> MI2 [BundledSucc=false, BundledPred=true]
>  
> Where MI1 is a spill, and MI2 is a different instruction, after
ExtendRanges we end up with
>  
> MI1 [BundledSucc=true,  BundledPred=false]
> DBG_VALUE MI [BundledSucc=false,  BundledPred=false]
> MI2 [BundledSucc=false, BundledPred=true]
>  
> Since this happens after the final instruction scheduling, it results in
broken schedules. I believe setting the bundling flags before invoking
MBB->insertAfter in ExtendRanges should fix this.
>  
> Best regards
> Saurabh Verma
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> 
> This e-mail and any attachments may contain confidential material for the
sole use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
> 
> 
> <dbg_value_fix.patch>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi,

Any help in pushing this change through would be greatly appreciated. As I
mentioned in my previous email, this bug causes breakage of VLIW bundles and
results in incorrect schedules when debug info gets generated and is hence an
important one to fix. My previous post had a small patch with the fix.

Best regards
Saurabh Verma

From: Verma, Saurabh
Sent: Friday, December 22, 2017 2:28 PM
To: 'llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org>
Subject: RE: DBG_VALUE insertion for spills breaks bundles

Hi again,

Here is a small patch to fix this issue.  Please note that since the problem
results in broken bundles, it can result in invalid schedules for any VLIW
back-ends using bundling to group instructions.

Best regards
Saurabh Verma

From: Verma, Saurabh
Sent: Tuesday, December 19, 2017 4:14 PM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: DBG_VALUE insertion for spills breaks bundles

Hi,

The insertion of DBG_VALUE instructions for spills does not seem to be handling
insert locations inside bundles well. If the spill instruction is part of a
bundle, the new DBG_VALUE is inserted after it, but does not have the bundling
flags set. This essentially means that if we start with a set of bundled
instructions:

MI1 [BundledSucc=true,  BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]

Where MI1 is a spill, and MI2 is a different instruction, after ExtendRanges we
end up with

MI1 [BundledSucc=true,  BundledPred=false]
DBG_VALUE MI [BundledSucc=false,  BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]

Since this happens after the final instruction scheduling, it results in broken
schedules. I believe setting the bundling flags before invoking
MBB->insertAfter in ExtendRanges should fix this.

Best regards
Saurabh Verma
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/0405d41c/attachment-0001.html>