similar to: [LLVMdev] [cfe-dev] Clang code generation

----- Original Message ----- > From: "Simone Atzeni" <simone.at at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, cfe-dev at cs.uiuc.edu, openmp-dev at dcs-maillist2.engr.illinois.edu > Sent: Tuesday, October 21, 2014 3:52:38 PM > Subject: Re: [LLVMdev] [cfe-dev][Openmp-dev] Provide LLVM IR and OpenMP LLVM IR as input

Hi Aboud, > On Mar 31, 2016, at 11:06 AM, Aboud, Amjad via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Hi Eric, > I can understand the need for improving the current design of debug info representation and emission in LLVM. > However, let’s not forget that the motivation was and still to support CodeView debug info emission. Well, that is *one* motivation. > I am

----- Original Message ----- > From: "Simone Atzeni" <simone.at at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, cfe-dev at cs.uiuc.edu, openmp-dev at dcs-maillist2.engr.illinois.edu > Sent: Tuesday, October 21, 2014 3:42:03 PM > Subject: Re: [LLVMdev] [cfe-dev][Openmp-dev] Provide LLVM IR and OpenMP LLVM IR as input

Hi, I am writing a plugin to get information about the OpenMP constructs from the AST. I am basically writing a “RecursiveASTVisitor” and I am trying to find the OpenMP statement and get information like filename and line of code. When I am visiting recursively each statement I have my own switch on the “StmtClass” and for now I am focusing on “OMPParallelForDirectiveClass”. In my understanding,

----- Original Message ----- > From: "Simone Atzeni" <simone.at at gmail.com> > To: llvmdev at cs.uiuc.edu, cfe-dev at cs.uiuc.edu, openmp-dev at dcs-maillist2.engr.illinois.edu > Sent: Tuesday, October 21, 2014 3:17:07 PM > Subject: Re: [LLVMdev] [cfe-dev][Openmp-dev] Provide LLVM IR and OpenMP LLVM IR as input in a Pass > > > > Hi all, > I am going

The split between CodeView and DWARF will happen at the level of type information. So, DIVariable, DISubprogram, DILocation, DILocalScope, etc will all be shared, but records and composite types etc will not. On Thu, Mar 31, 2016 at 3:44 PM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Mehdi, > > I understand the reasoning for supporting this proposal

Skipping a serialization and doing something clever about LTO uniquing sounds awesome. I'm guessing you achieve this by extracting types out of DI metadata and packaging them as lumps-o-DWARF that the back-end can then paste together? Reading between the lines a bit here. Can you share data about how much "pure" types dominate the size of debug info? Or at least the current

Thanks for sharing this. Mostly seems like a reasonable plan to me. A few comments below. On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi All, > > This is something that's been talked about for some time and it's probably > time to propose it. > > The "We" in this document is everyone on the cc line

On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < > Paul_Robinson at playstation.sony.com> wrote: > >> Skipping a serialization and doing something clever about LTO uniquing >> sounds awesome. I'm guessing you achieve this by extracting types out of

On Mar 31, 2016 7:11 PM, "David Blaikie" <dblaikie at gmail.com> wrote: > > > > On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: >> >> >> >> On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: >>> >>> Skipping a

> On Mar 31, 2016, at 8:50 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 31, 2016, at 7:11 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev <cfe-dev at lists.llvm.org

On Tue, Mar 29, 2016 at 7:43 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Thanks for sharing this. Mostly seems like a reasonable plan to me. A few >> comments below. >> >> > Thanks Peter! > > >> On Tue, Mar 29, 2016 at 6:00 PM, Eric

Hi all, I am going to build a Pass/es that verify OpenMP code. When we compile an OpenMP program we give the option “-fopenmp” to clang. In this way the LLVM IR code obtained will reflect also the “#pragma” keywords in the code, let’s call it "OpenMP LLVM IR". In my Pass/es before obtaining the OpenMP LLVM IR, I need to do some operation in the LLVM IR, that is the IR code obtained

How will this affect other languages that generate debug info - not that you should care about those, I'm just curious - my Pascal compiler does not generate clang-style AST, and does not use clang at all. I currently have code that in uses DIBuilder directly... -- Mats On 30 March 2016 at 04:15, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > On Tue,

> On Mar 29, 2016, at 11:35 PM, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > How will this affect other languages that generate debug info - not that you should care about those, I'm just curious - my Pascal compiler does not generate clang-style AST, and does not use clang at all. I currently have code that in uses DIBuilder directly... I don’t think that

Metadata will do exactly this, but the cost is that because you didn't teach the optimizers about your metadata, they are free to drop it on the floor whenever they optimize. If you want something persistent, consider adding your own intrinsics or function calls that are appropriately annotated as readnone etc and hope they don't affect optimization too much. On Wed, Oct 23, 2013 at

>-----Original Message----- >From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Reid >Kleckner via cfe-dev >Sent: Wednesday, May 11, 2016 10:40 AM >To: Mehdi Amini <mehdi.amini at apple.com> >Cc: llvm-dev <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at lists.llvm.org> >Subject: Re: [cfe-dev] [llvm-dev] RFC: Up front type information

> On Mar 31, 2016, at 7:11 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > > On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul <Paul_Robinson at playstation.sony.com

On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sharing this. Mostly seems like a reasonable plan to me. A few > comments below. > > Thanks Peter! > On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi All, >> >> This is something that's been

Hi Mehdi, I understand the reasoning for supporting this proposal independently from CodeView support. However, I do not think that it is needed for supporting CodeView. When I say that my suggestion is more clean, I was pointing to CodeView support, assuming the changes in LLVM IR/Clang FE indicated in this proposal. Also, it is not that clear from the proposal what will be shared (generic)