search for: pharr

On Apr 24, 2012, at 5:36 AM, Renato Golin wrote: > On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: >> When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been...

On Tue, Sep 6, 2011 at 4:37 PM, Matt Pharr <matt.pharr at gmail.com> wrote: > I'm seeing some behavior that surprised me in writing an <8 x i1> vector to memory and reading it back.  (Specifically, the surprise is that I didn't get the original value back!).  This happens both with TOT and 2.9.  This program illustrat...

I'm seeing some behavior that surprised me in writing an <8 x i1> vector to memory and reading it back. (Specifically, the surprise is that I didn't get the original value back!). This happens both with TOT and 2.9. This program illustrates the issue: define i32 @foo() { %c = alloca <8 x i1> store <8 x i1> <i1 true, i1 false, i1 false, i1 false, i1 false, i1

On Fri, Nov 4, 2011 at 10:46 AM, Matt Pharr <matt.pharr at gmail.com> wrote: > r143524 changed ModuleLinker such that when linking a Module B into a Module A, any internal/private/... functions in B are only linked into A if there is a use of them in A.  This is problematic for my usage of module linking, where I'm basically lin...

r143524 changed ModuleLinker such that when linking a Module B into a Module A, any internal/private/... functions in B are only linked into A if there is a use of them in A. This is problematic for my usage of module linking, where I'm basically linking a few modules together (some of which include internal functions) and then generating additional code that may use some of the internal

On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: > When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stri...

When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR. (e.g. in the MD for DW_TAG_compile_unit's list of subprograms, each of those functions' info is still in the list,

...like to know whether those assertions are there to enforce the specified restrictions or whether they are there to prevent bad things from happening downstream, and b) if the change is possible, it'd be nice to have it in the general distribution. Thanks for any help/guidance. -matt -- Matt Pharr http://pharr.org/matt

...thank everyone involved with the project for building such a great system. Thanks, -matt PS: I'm very much looking forward to David Greene's AVX work landing in the development branch--I expect that ispc will deliver interesting results on AVX very quickly at that point as well! -- Matt Pharr http://pharr.org/matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110621/b1317ac2/attachment.html>

I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot). However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create(). I assume that I'm just not doing something necessary for initialization, but I'm not sure what it would be--I am

...Note that I have just today filed a bug report also related to jitted > AVX: http://llvm.org/bugs/show_bug.cgi?id=10742 > Thus, it might very well be the case that I am also mistaken and need to > do something different. > > Best, > Ralf > > Am 25.08.2011 13:16, schrieb Matt Pharr: >> I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot).  However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create().  I assume th...

It seems that one of the optimization passes (it seems to be SROA) sometimes transforms computations on vectors of ints to computations on wide integer types; for example, I'm seeing code like the following after optimizations(*): %0 = bitcast <16 x i8> %float2uint to i128 %1 = shl i128 %0, 8 %ins = or i128 %1, 255 %2 = bitcast i128 %ins to <16 x i8> The back end I'm

...gine *ee = engineBuilder.create(); Note that I have just today filed a bug report also related to jitted AVX: http://llvm.org/bugs/show_bug.cgi?id=10742 Thus, it might very well be the case that I am also mistaken and need to do something different. Best, Ralf Am 25.08.2011 13:16, schrieb Matt Pharr: > I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot). However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create(). I assume that I...

...ted >>> AVX: http://llvm.org/bugs/show_bug.cgi?id=10742 >>> Thus, it might very well be the case that I am also mistaken and need to >>> do something different. >>> >>> Best, >>> Ralf >>> >>> Am 25.08.2011 13:16, schrieb Matt Pharr: >>>> I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot). However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create(). I a...

Filed as http://llvm.org/bugs/show_bug.cgi?id=12678. On Apr 23, 2012, at 2:03 PM, llvmdev-request at cs.uiuc.edu wrote: > I'm seeing some strange behavior with generating debugging information from a simple program. (LLVM top of tree, minus a couple of days.) > > I suspect that there is a bug in LLVM, but thought I'd check in here to see if perhaps I'm doing something

I agree that a single vector index is sufficient for many cases. Matt Pharr (from the ISPC compiler), showed me an interesting case where there is a single pointer into an array. In this case we need to have two indices, where the first index is zero. Once the basic patch is in, we can start looking at adding support for arrays and multiple indices. Nadav -----Original...

...reference to `vtable for llvm::PPCInstPrinter' However, I noticed that lli does neither call InitializeAllTargetMCs(), nor does it call LLVMLinkInMCJIT() and LLVMLinkInJIT(). Adapting my code to lli yields the same problem as for lli (unknown object format). Any more ideas? Best, Ralf Matt Pharr wrote: > Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) > > -matt > > Program received signal EXC...

...d a bug report also related to jitted >> AVX: http://llvm.org/bugs/show_bug.cgi?id=10742 >> Thus, it might very well be the case that I am also mistaken and need to >> do something different. >> >> Best, >> Ralf >> >> Am 25.08.2011 13:16, schrieb Matt Pharr: >>> I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot). However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create(). I assum...

On Jul 31, 2011, at 10:49 PM, Matt Pharr wrote: > I'm seeing some undesirable behavior where, when generating debugging information, sometimes the point in the debugger will jump forwards and backwards during single stepping, even though the output from our frontend (this is the ispc compiler), is emitting LLVM instructions with a...

On Aug 1, 2011, at 3:27 PM, Devang Patel wrote: > What do you see after instruction select ? Good question--I just checked. Things are still in the right order going into the x86 DAG->DAG instruction select pass, but then are out of order coming out of it. So that looks like the culprit... > I'll take a look at this. Meanwhile, please file bugzilla report so that this does not