search for: l224

...n that "hijacked" the overlay and included itself between the realFS and the memoryFS. It obtains files from the database! > > See: > https://github.com/Ericsson/CodeCompass/blob/a1a7b10e3a9e2e4f493135ea68566cee54adc081/plugins/cpp_reparse/service/src/databasefilesystem.cpp#L191-L224 <https://github.com/Ericsson/CodeCompass/blob/a1a7b10e3a9e2e4f493135ea68566cee54adc081/plugins/cpp_reparse/service/src/databasefilesystem.cpp#L191-L224> > > These files *do not necessarily* (in 99% of the cases, not at all) exist on the hard drive at the moment of the code wanting to p...

I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support. (The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists) https://reviews.llvm.org/D54277 proposed adding a function to VirtualFileSystem to get the underlying "real file" path from a VFS path. LLDB is starting to use VFS for some filesystem

On 05/01/2020 01:40 PM, Wyatt Childers via llvm-dev wrote: > I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect. > > While I haven't performed this particular trick on Github, based on my experience

On 11 June 2017 at 14:04, don hinton <hintonda at gmail.com> wrote: > Assuming you know it's a 64 bit value, and the function you are calling > takes a uint64_t, try this: > The values from the test program are of type: i32/i32*/i32**. Can't I interpret these as uint64_t some way? > > Value* args[] = {store_inst->getOperand(0)}; > > > On Sun, Jun 11,

I'm trying to determine the best way to index facets with multiple values. For example, let's say we have several books and we want an Author facet where one can filter the books by the author. The problem is each book can have multiple authors. Is there a way to index multiple author names into a single value slot for each book? I see there is a Xapian::StringListSerialiser class that

...urn we restore the registers from the stack. Essentially we're doing a context-switch, which might be what you're looking to do as well. That code is in compiler-rt hand-written as x86_64 assembly. See https://github.com/llvm-mirror/compiler-rt/blob/master/lib/xray/xray_trampoline_x86_64.S#L224 for some inspiration. The custom event instrumentation points just call into the trampoline, setting up the arguments on the spot. We've had to do some gymnastics to make that happen all the way up to the IR -- i.e. we insert the instrumentation as calls to LLVM intrinsics at the IR, and prese...

I'm still somewhat unclear about what you mean by "metadata record entry at the beginning of the block". I understand that I can make a MetadataRecord that contains the pid/tid since a metadata record contains 16 bytes. However, I don't understand what do you mean by the "beginning of the block". Do you mean right after the file header? My understanding is that at

...t; Of course, once the coro-split SCC pass has done all this, it must > update LLVM's representation of the call graph. It does so using ~40 > lines of code that you may read here: > https://github.com/llvm/llvm-project/blob/890c6ef1fb/llvm/lib/Transforms/Coroutines/Coroutines.cpp#L186-L224 > > To explain my understanding of the code in the above link: the > coro-split pass completely re-initializes the 'CallGraphSCC' object, > using the member function > 'CallGraphSCC::initialize(ArrayRef<CallGraphNode*>)'. The array of > nodes it uses to re-in...

Hello Dean, I looked at the XRay Instrumentation. That's a nice engineering effort. I am sure you had your motivation to do this in CodeGen just like I wanted to do. I don't understand all of your code but I get the idea that you are adjusting the alignment with explicit bytes and no-op instructions. My problem is also very much related to yours where my stack pointer ($rsp) alignment

...he > stack. Essentially we're doing a context-switch, which might be what you're > looking to do as well. That code is in compiler-rt hand-written as x86_64 > assembly. > > See > https://github.com/llvm-mirror/compiler-rt/blob/master/lib/xray/xray_ > trampoline_x86_64.S#L224 > for some inspiration. > > The custom event instrumentation points just call into the trampoline, > setting up the arguments on the spot. We've had to do some gymnastics to > make that happen all the way up to the IR -- i.e. we insert the > instrumentation as calls to LLVM in...