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

[Björn Pettersson A via llvm-dev]

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