search for: hsiangkai

> On Apr 1, 2018, at 9:12 AM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: > > Hi all, > > I am sorry that I didn’t carefully think about how to handle labels in > inlined function. There is no need to apologize! Thank you very much for engaging in the discussion and for contributing you patches. > > Toda...

...abel DIE from the DBG_LABEL Machine Instruction) yet. I attempted to implement these features, do you want me to submit the patches? Son Tuan Vu On Mon, Apr 2, 2018 at 5:37 PM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On Apr 1, 2018, at 9:12 AM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: > > > > Hi all, > > > > I am sorry that I didn’t carefully think about how to handle labels in > > inlined function. > > There is no need to apologize! Thank you very much for engaging in the > discussion and for cont...

...Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com wrote: > > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via >> llvm-dev >> Sent: Thursday, March 29, 2018 1:54 PM >> To: aprantl at apple.com; hsiangkai at gmail.com >> Cc: llvm-dev at lists.llvm.org >> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in >> Function >> >>> Based on that I think it might be sufficient to have a flag on an IR >> label >>> that marks a user-originated...

...Debug Information for Labels in > > Function > > > > > > > > > On Mar 30, 2018, at 9:25 AM, Adrian Prantl via llvm-dev <llvm- > > dev at lists.llvm.org> wrote: > > > > > > > > > > > >> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <hsiangkai at gmail.com> > > wrote: > > >> > > >> I agree with you. Attach debug metadata to basic block will be a > > >> better solution. I will change my design to convey debug metadata > > >> through basic block instead of intrinsi...

> -----Original Message----- > From: aprantl at apple.com [mailto:aprantl at apple.com] > Sent: Thursday, March 29, 2018 2:23 PM > To: Robinson, Paul > Cc: hsiangkai at gmail.com; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in > Function > > > > > On Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com wrote: > > > > > > > >> -----Original Message----- > &...

Hi all, I am sorry that I didn’t carefully think about how to handle labels in inlined function. Today, I did some simple experiments and found that some basic block may be removed in CFGSimplifyPass and the attached metadata will be eliminated. So, if the optimization is turned on, label metadata will disappear. However, intrinsic will keep existing in the function if we handle it correctly.

> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: > > I agree with you. Attach debug metadata to basic block will be a > better solution. I will change my design to convey debug metadata > through basic block instead of intrinsic. > > https://reviews.llvm.org/D45078 In this revised de...

On Fri, Mar 30, 2018 at 9:39 AM Adrian Prantl <aprantl at apple.com> wrote: > I'm really sorry for not realizing this yesterday, but the problems > pertaining to inlining made me realize that your original design with the > dbg.label intrinsic might actually be a better approach especially when > considering optimized code. We will get inlining support for free because >

On Fri, Mar 30, 2018 at 12:05 AM, Adrian Prantl <aprantl at apple.com> wrote: >> >> On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello all, >> >> I would like to enhance LLVM debug info that supports setting >> breakpoint on labels in function. >> >> Generally, if users use GDB as their debugger, they could set >&gt...

> On Mar 30, 2018, at 9:25 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: >> >> I agree with you. Attach debug metadata to basic block will be a >> better solution. I will change my design to convey debug metadata >> through basic block instead of intrinsic. >> >> https://reviews.llvm.org/D4...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via > llvm-dev > Sent: Thursday, March 29, 2018 1:54 PM > To: aprantl at apple.com; hsiangkai at gmail.com > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in > Function > > > Based on that I think it might be sufficient to have a flag on an IR > label > > that marks a user-originated label and triggers the ba...

> Based on that I think it might be sufficient to have a flag on an IR label > that marks a user-originated label and triggers the backend to create a > DW_TAG_label for it. If we do need source location information for the > DW_TAG_label, we could grab it from the first instruction. Are there languages where labels are scoped? If so we'd need explicit metadata to identify the

> On Mar 29, 2018, at 11:51 AM, paul.robinson at sony.com wrote: > > > >> -----Original Message----- >> From: aprantl at apple.com [mailto:aprantl at apple.com] >> Sent: Thursday, March 29, 2018 2:23 PM >> To: Robinson, Paul >> Cc: hsiangkai at gmail.com; llvm-dev at lists.llvm.org >> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in >> Function >> >> >> >>> On Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com wrote: >>> >>> >>> >>>...

Hello all, I would like to enhance LLVM debug info that supports setting breakpoint on labels in function. Generally, if users use GDB as their debugger, they could set breakpoints on labels in function. Following is an example. // C program static int myfunction (int arg) { int i, j, r; j = 0; /* myfunction location */ r = arg; top: ++j; /* top location */ if (j == 10) goto

LGTM. I think you can sent patch and let the ball rolling! I would like to review it. ;) 2018-03-28 10:41 GMT+08:00 Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org>: > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on labels in function. Follow...

Sounds good to me. You can also see llvm.codeview.annotation which does a similar thing, but it is modeled as having internal, invisible side effects. These should stay separate, but it may provide a guide for implementation. On Tue, Mar 27, 2018 at 7:41 PM Hsiangkai Wang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on labels in function...

...re any problem to assume vscale to be fractional under some circumstances? vscale should be an unknown value when compiling. So, it should have no impact on code generation and optimization. The relationship between types is correct regardless vscale’s value. Is there anything I missed? Thanks! Hsiangkai -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/42c81c72/attachment-0001.html>

> > On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on labels in fu...

...) Liu [proposes](http://lists.llvm.org/pipermail/cfe-dev/2018-March/057426.html) adding a HIP language mode to Clang. HIP is a language with similarities to CUDA. * Michael Spencer [proposes using Markdown for LLVM documentation](http://lists.llvm.org/pipermail/llvm-dev/2018-March/122234.html). * Hsiangkai Wang is seeking feedback on an [RFC to generate debug info for labels in a function](http://lists.llvm.org/pipermail/llvm-dev/2018-March/122175.html). * LLVM 5.0.2-rc2 [has been tagged](http://lists.llvm.org/pipermail/llvm-dev/2018-March/122245.html). * Daniel Neilson has [reported back](http://l...

...ere any problem to assume vscale to be fractional under some circumstances? vscale should be an unknown value when compiling. So, it should have no impact on code generation and optimization. The relationship between types is correct regardless vscale’s value. Is there anything I missed? Thanks! Hsiangkai -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/335fa446/attachment.html>