similar to: Put ToolInvoker Output Into a String

Hi, I am using clang::ToolInvocation class to compile some code in-memory: clang::tooling::ToolInvocation ti ( compilerArgs, new clang::EmitBCAction(), new clang::FileManager(clang::FileSystemOptions()) ); //filename is the name of the source file, e.g. "Somefile.cpp" //sourcecode contains the source of the file ti.mapVirtualFile( filename,

Hi, I can confirm this problem. We use clang's libtooling ToolInvocation object and the second module fails to compile even through it's a completely fresh instance. Adding -fno-vectorize explicitly seems to work around this problem, but does anyone know a real fix? ciao, Mario Am 20.06.13 15:07, schrieb Alan Garny: > My application generates some C code which I then compile using

Hi, I'm writing to both lists as I'm not sure what the cause of this issue is. I use code like this to compile C source into LLVM IR as suggested on the Clang mailing list previously. class CompileBitcodeAction : public clang::EmitLLVMOnlyAction { protected: Module*& dstModule; public: inline CompileBitcodeAction(Module*& dstModule, LLVMContext* const context = NULL)

Hi folks, Warning: I don't know if the result I am getting makes sense, so this may be a statistics question. The fitted values from my binomial lmer mixed model seem to consistently overestimate the cell means, and I don't know why. I assume I am doing something stupid. Below I include code, and a binary image of the data is available at this link:

Hi, My application generates some C code which I then compile using LLVM+Clang before running it. For the compilation side of things, I have a class which one of the methods (the CompilerEngine::compileCode() method in https://raw.github.com/opencor/opencor/llvm_3.3/src/plugins/misc/Compiler/sr c/compilerengine.cpp) is based on the code from the clang-interpreter example

I think that 32-bit systems (especially ARM) may be short on memory so doubling the size of the table containing (potentially) all the functions may give a tangible overhead. I would even align the entries to 4 bytes (so 12 bytes per entry) on 32-bit platforms and to 8 bytes (so 24-bytes per entry) on 64-bit platforms, to improve CPU cache hits. What do you think? Cheers, Serge On 8 August 2016

On Thu, Sep 8, 2016 at 11:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 9 Sep 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> > wrote: > > > > > > > >> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote: > >> > >> But I take it you mean (as detailed later) to have a

> On 26 Aug 2016, at 03:26, Chris Bieneman <cbieneman at apple.com> wrote: > > I totally did not mean to make the response off list. > Thanks Chris, I'm adding the list to this response. Those interested should see the short discussion quoted below. Adding Chandler explicitly for points raised by Chris below. Thoughts? Cheers -- Dean > >> On Aug 24, 2016, at

I would be happy to help. Could you send me the example patch? Where would I submit my patch to be reviewed? Thanks, Henry On Mon, Jun 11, 2018 at 8:31 PM, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > > On 12 Jun 2018, at 07:49, Henry Zhu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > > > I’ve

Hi Dean, I have a question for 32-bit platforms. I see in the code that you used the following in compiler-rt/trunk/lib/xray/xray_interface_internal.h : struct XRaySledEntry { uint64_t Address; uint64_t Function; unsigned char Kind; unsigned char AlwaysInstrument; unsigned char Padding[14]; // Need 32 bytes }; And the peer code in llvm/trunk/lib/Target/X86/X86MCInstLower.cpp : void

> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote: > > (sorry for the delay) > All good, thanks Dave! > On Tue, Aug 23, 2016 at 1:05 AM Dean Michael Berris <dean.berris at gmail.com <mailto:dean.berris at gmail.com>> wrote: > Hi llvm-dev, > > I've been implementing a tool for analysing XRay traces. A recap of XRay's

Hi llvm-dev, I've been implementing a tool for analysing XRay traces. A recap of XRay's original RFC [0] mentions a tool that does function call accounting as a starting point. This is implemented currently in D21987 [1], and is being reviewed by David Blaikie. One key issue in that review is the dependency between the log format determined by the XRay runtime implementation in

Hi Dean, We didn't discuss using XRay instrumentation during the BoF but it is an interesting idea (by the way, thanks for your talk about XRay internals!). XRay provides the advantage of being able to turn profiling on and off, but I'm not sure how the resulting data could be used. The code coverage feature is highly dependent on the frontend's profile counter placement. The mapping

Hi Dean, Do you have any estimates on when https://reviews.llvm.org/D21982 will reach mainline? (As I understood it's not yet there, looking at http://llvm.org/svn/llvm-project/compiler-rt/trunk ). I would like to test ARM port of XRay, so ready logging would be handful. Thanks, Serge On 8 August 2016 at 17:41, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 8

On 30 November 2016 at 05:08, Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> wrote: > - Is there a preference between the two options provided above? > - Any other alternatives we should consider? > - Which parts of which options do you prefer, and is there a synthesis of either of those options that appeals to you? Hi Dean, I haven't followed the XRay project

If a transform feedback buffer's size is 0, st_bufferobj_data doesn't end up creating a buffer for it. There's no point in trying to write to such a buffer, so just pretend as if it's not really there. This fixes arb_gpu_shader5-xfb-streams-without-invocations on nvc0. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/mesa/state_tracker/st_cb_xformfb.c | 2 +- 1

> On Sep 14, 2016, at 12:50 AM, Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm working on this now, and I had a few more questions below for Renato and the list in general. Please see inline below. > >> On 2 Sep 2016, at 11:27, Dean Michael Berris <dean.berris at gmail.com> wrote: >> >>> On 2 Sep 2016, at 11:19,

Have you seen the prototype for googlebenchmark integration I did in the past: https://reviews.llvm.org/D18428 <https://reviews.llvm.org/D18428> (though probably out of date for todays test-suite) +1 for copying the googlebechmark into the test-suite. However I do not think this should simply go into MultiSource: We currently have a number of additional plugins in the lit test runner such

> On 2 Sep 2016, at 11:19, Renato Golin <renato.golin at linaro.org> wrote: > > On 2 September 2016 at 02:13, Dean Michael Berris <dean.berris at gmail.com> wrote: >> I think it should be possible to have a snapshot of it included. I don't know what the licensing implications are (I'm not a lawyer, but I know someone who is -- paging Danny Berlin). > >

On Thu, Jan 17, 2019 at 2:47 PM Xinliang David Li <davidxl at google.com> wrote: > > > On Thu, Jan 17, 2019 at 2:32 PM Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com> >> wrote: >> >>> Hi Manman, >>> >>> Ordering profiling is