Displaying 20 results from an estimated 40 matches for "ragan".
Did you mean:
kagan
2012 Sep 14
4
[LLVMdev] Atomic ops cannot be built from C/OCaml bindings
Forgive me if I'm missing something obvious, but it seems that a
number of core instructions—I'm specifically running in to
`atomicrmw`, `fence`, and `cmpxchg` at the moment—cannot be
constructed from the C bindings, and are therefore also inaccessible
to the OCaml bindings. There are opcodes for each of these in the
llvm-c/Core.h, but there seems to be no way to construct them.
Is there
2012 Oct 05
2
[LLVMdev] Atomic ops cannot be built from C/OCaml bindings
How soon would I need to submit a patch for this for it to have a comfortable shot at making it into the 3.2 release?
On Sep 14, 2012, at 8:05 PM, Eric Christopher <echristo at apple.com> wrote:
>
> On Sep 14, 2012, at 4:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote:
>
>> Is there a reason these should be omitted?
>
> Not in particular. Things are added to the C API as needed and usually on demand.
>
> -eric
2006 Sep 14
2
Adding predicted values as a new variable in a data frame
...s a new column to the data set when you find the fitted values. So
having to fight with R just to do something I used to routimely do has
made me think of turning back to the dark side. I hope I have just
missed something trival in all the help files I have been
looking through.
Thanks,
--
Robi Ragan
Graduate Student
Department of Economics
Department of Political Science
The University of Georgia
2009 May 29
3
[LLVMdev] RFC: Atomics.h
On May 28, 2009, at 6:03 PM, Jonathan Ragan-Kelley wrote:
> In the current trunk, System/Atomic.[h,cpp] define void
> llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in
> <windows.h> and (since it's a preprocessor macro, and not a scoped
> function definition) causes the sys::MemoryFence definition...
2012 Oct 24
0
[LLVMdev] Atomic ops cannot be built from C/OCaml bindings
I finally got around to adding these.
The patch is posted in a pull request on my copy of llvm.git:
https://github.com/jrk/llvm/pull/3
and a simple test with OCaml is here:
https://gist.github.com/3948460
Feedback welcome.
On Sep 14, 2012, at 7:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote:
> Forgive me if I'm missing something obvious, but it seems that a
> number of core instructions—I'm specifically running in to
> `atomicrmw`, `fence`, and `cmpxchg` at the moment—cannot be
> constructed from the C bindings, and are th...
2009 Jun 02
0
[LLVMdev] RFC: Atomics.h
Yes, indeed.
On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote:
>
> Wait, it defines MemoryFence() AND MemoryBarrier()??
>
> Sheesh, they had to take all the reasonable names. :-/
2009 Jun 02
1
[LLVMdev] RFC: Atomics.h
On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote:
> Yes, indeed.
Are they macros or functions? If macros, why not just #undef them at
the top of Atomics.h?
-Chris
>
>
> On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote:
>>
>> Wait, it defines MemoryFence() AND MemoryBarrier()??
>&g...
2009 Jun 04
2
[LLVMdev] Windows x64 JIT usability
What is the current state of the JIT on Windows x64?
I have noticed intermittent conversation about past incompatibility
due to the calling convention idiosyncrasies, as well as some
suggestion from last fall that it was targeted for a fix in the 2.5
timeframe, but see no definitive conclusion. Is this working in 2.5,
in trunk, or likely to be in trunk soon?
2009 Jun 04
0
[LLVMdev] Windows x64 JIT usability
On Wed, Jun 3, 2009 at 6:29 PM, Jonathan Ragan-Kelley<jrk at csail.mit.edu> wrote:
> What is the current state of the JIT on Windows x64?
Broken; at the very least, there's http://llvm.org/bugs/show_bug.cgi?id=3739 .
-Eli
2011 Apr 17
0
[LLVMdev] Xcode 4 autocomplete of LLVM includes
Jonathan Ragan-Kelley <katokop1 <at> gmail.com> writes:
>
> Slightly off-topic, but I imagine this crowd must have some experience
> using Xcode 4 for projects linking to LLVM. I've actually started
> using Xcode 4 as an IDE for C/C++ development thanks to the vastly
> improved co...
2011 May 13
2
[LLVMdev] Does the OCaml binding include intrinsic support?
I can't seem to find reference to intrinsics, beyond the is_intrinsic function.
I am building a backend which needs to perform some target-specific
code-generation (for SSE, AVX, and NEON), and intrinsics are the
standard path in the C++ API.
2011 May 14
0
[LLVMdev] Does the OCaml binding include intrinsic support?
On Fri, May 13, 2011 at 5:18 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu>wrote:
> I can't seem to find reference to intrinsics, beyond the is_intrinsic
> function.
>
> I am building a backend which needs to perform some target-specific
> code-generation (for SSE, AVX, and NEON), and intrinsics are the
> standard...
2012 Sep 15
0
[LLVMdev] Atomic ops cannot be built from C/OCaml bindings
On Sep 14, 2012, at 4:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote:
> Is there a reason these should be omitted?
Not in particular. Things are added to the C API as needed and usually on demand.
-eric
2011 Mar 22
2
[LLVMdev] Xcode 4 autocomplete of LLVM includes
Slightly off-topic, but I imagine this crowd must have some experience
using Xcode 4 for projects linking to LLVM. I've actually started
using Xcode 4 as an IDE for C/C++ development thanks to the vastly
improved code analysis-based tools it's inherited largely thanks to
LLVM. But, ironically, I am particularly struggling to get the tools
to parse and analyze LLVM (as a client, not for
2011 Dec 28
0
[LLVMdev] Linkage warning in current trunk
On 28.12.2011, at 19:02, Jonathan Ragan-Kelley wrote:
> Building on OS X 10.7.1 with the standard toolchain, I have seen the
> following linker warnings going back a number of versions in trunk
> whenever I build an executable linked with LLVM:
>
> ld: warning: direct access in llvm::fouts() to global weak
> sy...
2015 Jan 12
3
[LLVMdev] Emitting IR in older formats (for NVVM)
This question is specifically motivated by the practical constraints of
NVVM, but I don't know anywhere better to ask (hopefully, e.g.,
@jholewinski is still following), and I believe it concerns general LLVM
issues:
NVIDIA's libNVVM is built on LLVM 3.2. This means its bitcode and LL text
parsers are from that generation. It's interface calls for adding modules
as either bitcode
2015 Jan 13
2
[LLVMdev] Emitting IR in older formats (for NVVM)
Thanks, all.
I didn’t realize a 7.0 RC was public and changed to 3.4—I will go down that road for now, though I’ll probably also look into integrating variants of the SPIR converter in the future.
Another possibility is to skip libnvvm altogether and use LLVM's NVPTX target. This is of course harder since you have to configure the passes yourself instead of just calling a few C
2011 Dec 28
2
[LLVMdev] Linkage warning in current trunk
Building on OS X 10.7.1 with the standard toolchain, I have seen the
following linker warnings going back a number of versions in trunk
whenever I build an executable linked with LLVM:
ld: warning: direct access in llvm::fouts() to global weak
symbol llvm::formatted_raw_ostream::~formatted_raw_ostream() means the
weak symbol cannot be overridden at runtime. This was likely caused by
2015 Jan 13
2
[LLVMdev] Emitting IR in older formats (for NVVM)
Since SPIR can be (easily) transformed to NVVM IR at least for me this helps a lot.
Thank you Tobias.
-MH
On January 12, 2015, Tobias Grosser <tgrosser at inf.ethz.ch> wrote:
> On 12.01.2015 05:48, Jonathan Ragan-Kelley wrote:
> > This question is specifically motivated by the practical constraints of
> > NVVM, but I don't know anywhere better to ask (hopefully, e.g.,
> > @jholewinski is still following), and I believe it concerns general LLVM
> > issues:
> >
> > NVI...
2011 Dec 28
1
[LLVMdev] Fix for OCaml bindings
The OCaml bindings have been broken in trunk for a while. I chased it
down to the addition of the Half type (rev 146786) not being reflected
in the OCaml enums, causing mysterious type checking to break in the
middle of the LLVM stack when using code generated from OCaml.
The fix was trivial:
https://github.com/jrk/llvm/pull/1/files
-------------- next part --------------
A non-text attachment