similar to: Question about __NSConstantString and __NSConstantString_tag

> On Feb 19, 2016, at 7:16 AM, Brad King <brad.king at kitware.com> wrote: > > On 02/18/2016 05:51 PM, Michka Popoff wrote: >> Our problem is that the AST contains some declarations which were not there before. > [snip] >> __NSConstantString and __NSConstantString_tag are now exposed. > [snip] >> Maybe someone could enlighten us about this change. >>

> On Feb 25, 2016, at 7:49 AM, Brad King <brad.king at kitware.com> wrote: > > On 02/19/2016 10:35 AM, Ben Langmuir wrote: >>> On Feb 19, 2016, at 7:16 AM, Brad King wrote: >>> [snip] >>>> __NSConstantString and __NSConstantString_tag are now exposed. >>> To clarify, this is not so much about the appearance of new builtins >>> but

On 02/19/2016 10:35 AM, Ben Langmuir wrote: >> On Feb 19, 2016, at 7:16 AM, Brad King wrote: >> [snip] >>> __NSConstantString and __NSConstantString_tag are now exposed. >> To clarify, this is not so much about the appearance of new builtins >> but that the structure has fields with no name. Other builtin >> structures like __va_list_tag have names on their

Hi, I would like to implement macro debug info support in LLVM. Below you will find 4 parts: 1. Background on what does it mean to debug macros. 2. A brief explanation on how to represent macro debug info in DWARF 4.0. 3. The suggested design. 4. A full example: Source -> AST -> LLVM IR -> DWARF. Feel free to skip first two parts if you think you know the background.

I'd like to jump in. I do not work on a preprocessor based language, but have the same code expansion problem to encode. Right now, we hack around the problem by appending some prefix after the file name and pretend it is a different file, which is not great. I understand you want to represent expansion by DIFileMacro ? I'm not how this is supposed to be used and it is not in the example.

> Not necessarily, if we kept the macros in order in the list of macros attached to the CU, which I imagine we would. OK, now I understand what you are aiming for. I really do not favor one on the other. But, can you explain what is the advantage of the parent approach over the children approach? If any, the children approach seems to be the one reduces the LLVM IR size, is not it? Regards,

> Right - I was wondering if CGDebugInfo already implemented PPCallbacks or was otherwise being notified of PPCallback related things, possibly through a layer or two of indirection. I checked the approach of skipping representing macros in AST, and communicate them directly from Parser to CGDebugInfo. However, I could not find a way to initialize this communication. The only interface

> Do we really need to touch the AST? Or would it be reasonable to wire up the CGDebugInfo directly to the PPCallbacks, if it isn't already? (perhaps it is already wired up for other reasons?) This sound as a good idea, I will check that approach. PPCallbacks is only an interface, has nothing connected to it, but we will create a new class, which implement PPCallbacks, for macros. So we can

On 02/25/2016 11:41 AM, Ben Langmuir wrote: > Thanks for the patch. Committed as r261887 Great, thanks! -Brad

On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> wrote: > I found a way to skip representing macros in AST and create them directly > in CGDebugInfo through PPCallbacks during preprocessing. > > To do that, I needed to extend ASTConsumer interface with this extra > method: > > > > /// If the consumer is interested in notifications from

On Fri, Nov 13, 2015 at 2:41 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Fri, Nov 13, 2015 at 10:21 AM, David Blaikie via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> >> wrote: >> >>> I found a way to skip representing macros in AST and create them

The recently added code: static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty, -INFINITY); if (V2->isNullValue()) return 0; BuiltinType R = (BuiltinType)V1->getValue() / (BuiltinType)V2->getValue(); return

On Mon, 2 May 2005, Jeff Cohen wrote: > The recently added code: > static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { > if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); > if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty, -INFINITY); > if (V2->isNullValue()) return 0; > BuiltinType R =

Yes, that will work. I'll make the change. Chris Lattner wrote: > On Mon, 2 May 2005, Jeff Cohen wrote: > >> The recently added code: >> static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { >> if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); >> if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty,

On Mon, 2 May 2005, Jeff Cohen wrote: > Yes, that will work. I'll make the change. While you're at it, please remove this line, which is dead: if (V2->isNullValue()) return 0; Thanks, -Chris > Chris Lattner wrote: > >> On Mon, 2 May 2005, Jeff Cohen wrote: >> >>> The recently added code: >>> static Constant *Div(const ConstantClass *V1,

Hi guys, I am trying to extract the class name of a parameter to a method call in objective-C. The code I am parsing is: - (void)testAddConcreteDataModel:(DFDemoDataModelOne*)helpmeh { [self.dataModels addObject:helpmeh]; } And the result I need is the type of class of helpmeh, which is "DFDemoDataModelOne". So far I have the following code, which outputs:

In various debug dumps (eg., Clang's -ast-dump), various objects (eg., Stmts and Decls in that -ast-dump) are identified by pointers. It's very reliable in the sense that no two objects would ever have the same pointer at the same time, but it's unpleasant that pointers change across runs. Having deterministic identifiers instead of pointers would aid debugging: imagine a

Hello, I am working on a tool which takes c++ header files and based on interfaces defined in them generates csharp classes and glue layer for interop. For analyzing the c++ code I am currently using clang, which parses the headers and writes output into xml via -ast-print-xml (yes, this unfortunately means that it is a very old version of clang). I then use these xml files to generate the csharp

This is a great idea! I personally also wouldn't mind going further in debug builds and actually create and store sequential IDs with the objects and take the small memory hit for improved debuggability. The `PersistentId` field in SelectionDAG works that way and has helped make the output more readable IMO. - Matthias > On Aug 28, 2018, at 5:22 PM, George Karpenkov via llvm-dev

Hi, I have implemented a recursive loop to go through all the user of a global variable but I have one issue left. Depending the code, the global variable is using itself: @sSelectedAccount = internal constant %struct.KVObserver { %0* bitcast (%struct.__NSConstantString_tag* @_unnamed_cfstring_.744 to %0*), i8* bitcast (%struct.KVObserver* @sSelectedAccount to i8*), i32 3 }, align 4 With the