llvm dev - Aug 2018 - [DWARF] prologue_end fix not working for VLIW

Hi,

I found that prologue_end markers where badly placed in my test, and 
applied https://reviews.llvm.org/D41762 in the hope that it would fix it 
(I'm on 4.0.1).
However, this fix doesn't work for VLIW architectures. At this point 
we're iterating over bundles, not MachineInstructions, and the 
FrameSetup flag is set on MachineInstructions, not bundles.
If bundling happens in the prologue we might insert the prologue_end 
marker too early.
Instead, we need to check whether all instructions in the bundle (if 
bundled) have the FrameSetup flag.
This assumes we want the prologue_end marker just before the first 
instruction not in the prologue. I couldn't find anything official about 
the placement in this case in the DWARF spec.
Since I am working on a custom target I'm afraid I can't provide any 
test cases...

Thanks,

-- 
Verena Beckham

Senior Principal Software Engineer, Compilers

Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson Street, Edinburgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com

This email and any attachments may contain confidential and /or 
privileged information and  is for use  by the addressee only. If you 
are not the intended recipient, please notify Codeplay Software Ltd 
immediately and delete the message from your computer. You may not copy 
or forward it,or use or disclose its contents to any other person. Any 
views or other information in this message which do not relate to our 
business are not authorized by Codeplay software Ltd, nor does this 
message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay 
Software Ltd does not accept any responsibility for any changes made to 
this message after it was sent. Please note that Codeplay Software Ltd 
does not accept any liability or responsibility for viruses and it is 
your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: Regent house, 316 Beulah Hill, London, United 
Kingdom, SE19 3HF

> -----Original Message-----
> From: Verena Beckham [mailto:verena at codeplay.com]
> Sent: Thursday, August 09, 2018 11:42 AM
> To: llvm-dev at lists.llvm.org
> Cc: Robinson, Paul
> Subject: [DWARF] prologue_end fix not working for VLIW
> 
> Hi,
> 
> I found that prologue_end markers where badly placed in my test, and
> applied https://reviews.llvm.org/D41762 in the hope that it would fix it
> (I'm on 4.0.1).
> However, this fix doesn't work for VLIW architectures. At this point
> we're iterating over bundles, not MachineInstructions, and the
> FrameSetup flag is set on MachineInstructions, not bundles.
> If bundling happens in the prologue we might insert the prologue_end
> marker too early.
> Instead, we need to check whether all instructions in the bundle (if
> bundled) have the FrameSetup flag.
> This assumes we want the prologue_end marker just before the first
> instruction not in the prologue. I couldn't find anything official
about
> the placement in this case in the DWARF spec.
prologue_end should identify the first instruction that is not part
of the prologue.  The interaction with bundles is deliberately not
part of the spec, as DWARF cannot anticipate the relevant factors for
all possible VLIW architectures.

For a previous compiler I worked on, we used low-order instruction
address bits as an instruction-within-bundle index, which allowed the
line table to identify individual instructions within a bundle.  These
were not real instruction addresses, obviously, but the compiler and
debugger agreed to that convention and it worked very well.  Whether
that's appropriate for your case, and whether you can persuade LLVM to
do something like that, is a different story.

Good luck, and feel free to ask questions here.
--paulr
> Since I am working on a custom target I'm afraid I can't provide
any
> test cases...
> 
> Thanks,
> 
> --
> Verena Beckham
> 
> Senior Principal Software Engineer, Compilers
> 
> Codeplay Software Ltd
> Level C, Argyle House, 3 Lady Lawson Street, Edinburgh, EH3 9DR
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> 
> This email and any attachments may contain confidential and /or
> privileged information and  is for use  by the addressee only. If you
> are not the intended recipient, please notify Codeplay Software Ltd
> immediately and delete the message from your computer. You may not copy
> or forward it,or use or disclose its contents to any other person. Any
> views or other information in this message which do not relate to our
> business are not authorized by Codeplay software Ltd, nor does this
> message form part of any contract unless so stated.
> As internet communications are capable of data corruption Codeplay
> Software Ltd does not accept any responsibility for any changes made to
> this message after it was sent. Please note that Codeplay Software Ltd
> does not accept any liability or responsibility for viruses and it is
> your responsibility to scan any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: Regent house, 316 Beulah Hill, London, United
> Kingdom, SE19 3HF

Hello Verena.

We are also doing VLIW for out out-of-tree target, and we have some patches (not
yet upstreamed) related to debug info (frame setup/destroy) and bundles.

I uploaded (at least some of) those patches here:
  https://reviews.llvm.org/D50637
  https://reviews.llvm.org/D50638
  https://reviews.llvm.org/D50639

I can't guarantee that the above patches will solve the problem for you. But
let me know if you find them useful.

Note that the current version of D50638 includes a target hook, so you need to
override that for your target.
And before using that hook you need to make sure your target is setting
FrameSetup/FrameDestroy on prologue/epilogue instructions.
(the D50638 patch won't help you with prologue_end anyway, it is about debug
location ranges)

Btw, I'd be happy if someone could review these patches, getting them merged
to trunk would reduce the number of out-of-tree patches that we have.

/Björn
> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of via
llvm-dev
> Sent: den 9 augusti 2018 18:48
> To: verena at codeplay.com; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [DWARF] prologue_end fix not working for VLIW
> 
> 
> 
> > -----Original Message-----
> > From: Verena Beckham [mailto:verena at codeplay.com]
> > Sent: Thursday, August 09, 2018 11:42 AM
> > To: llvm-dev at lists.llvm.org
> > Cc: Robinson, Paul
> > Subject: [DWARF] prologue_end fix not working for VLIW
> >
> > Hi,
> >
> > I found that prologue_end markers where badly placed in my test, and
> > applied https://reviews.llvm.org/D41762 in the hope that it would fix
it
> > (I'm on 4.0.1).
> > However, this fix doesn't work for VLIW architectures. At this
point
> > we're iterating over bundles, not MachineInstructions, and the
> > FrameSetup flag is set on MachineInstructions, not bundles.
> > If bundling happens in the prologue we might insert the prologue_end
> > marker too early.
> > Instead, we need to check whether all instructions in the bundle (if
> > bundled) have the FrameSetup flag.
> > This assumes we want the prologue_end marker just before the first
> > instruction not in the prologue. I couldn't find anything official
about
> > the placement in this case in the DWARF spec.
> 
> prologue_end should identify the first instruction that is not part
> of the prologue.  The interaction with bundles is deliberately not
> part of the spec, as DWARF cannot anticipate the relevant factors for
> all possible VLIW architectures.
> 
> For a previous compiler I worked on, we used low-order instruction
> address bits as an instruction-within-bundle index, which allowed the
> line table to identify individual instructions within a bundle.  These
> were not real instruction addresses, obviously, but the compiler and
> debugger agreed to that convention and it worked very well.  Whether
> that's appropriate for your case, and whether you can persuade LLVM to
> do something like that, is a different story.
> 
> Good luck, and feel free to ask questions here.
> --paulr
> 
> > Since I am working on a custom target I'm afraid I can't
provide any
> > test cases...
> >
> > Thanks,
> >
> > --
> > Verena Beckham
> >
> > Senior Principal Software Engineer, Compilers
> >
> > Codeplay Software Ltd
> > Level C, Argyle House, 3 Lady Lawson Street, Edinburgh, EH3 9DR
> > Tel: 0131 466 0503
> > Fax: 0131 557 6600
> > Website: http://www.codeplay.com
> >
> > This email and any attachments may contain confidential and /or
> > privileged information and  is for use  by the addressee only. If you
> > are not the intended recipient, please notify Codeplay Software Ltd
> > immediately and delete the message from your computer. You may not
> copy
> > or forward it,or use or disclose its contents to any other person. Any
> > views or other information in this message which do not relate to our
> > business are not authorized by Codeplay software Ltd, nor does this
> > message form part of any contract unless so stated.
> > As internet communications are capable of data corruption Codeplay
> > Software Ltd does not accept any responsibility for any changes made
to
> > this message after it was sent. Please note that Codeplay Software Ltd
> > does not accept any liability or responsibility for viruses and it is
> > your responsibility to scan any attachments.
> > Company registered in England and Wales, number: 04567874
> > Registered office: Regent house, 316 Beulah Hill, London, United
> > Kingdom, SE19 3HF
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev