similar to: [LLVMdev] RFC: Patch for CFA on Darwin

Bill, > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. Please ignore my prev. e-mail. The code breaks at least 32-bit stuff. The arg of

Hi all, Here's a potential patch for LLVM-GCC: Index: llvm-convert.cpp =================================================================== --- llvm-convert.cpp (revision 41260) +++ llvm-convert.cpp (working copy) @@ -4240,11 +4240,12 @@ return false; int cfa_offset = ARG_POINTER_CFA_OFFSET(0); - - Result = Builder.CreateCall(Intrinsic::getDeclaration(TheModule, -

Hello, Bill > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. How do you like the one attached? It seems to be much more clear to fix codegen

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier"

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >

On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0,

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

Hi, I was talking with aKor in #llvm how we could implement custom operation support for our ASIP architecture. We came into solution that the best way would be to write new custom operation intrinsic and optimization pass for raising certain type of function calls to those intrinsics (similar to raising mallocs). Basically our custom operation are like calls, with operand name and multiple

On Tue, 31 Jul 2007, [ISO-8859-1] Mikael Lepist� wrote: > I was talking with aKor in #llvm how we could implement custom operation > support for our ASIP architecture. We came into solution that the best > way would be to write new custom operation intrinsic and optimization > pass for raising certain type of function calls to those intrinsics > (similar to raising mallocs). >

Hi, I've been hitting my head to wall two days now. This is practically my first contact with InstrInfo.td files. Is there any tutorial how to make this kind of stuff? Or should I just keep on studying Sparc and other backends? So I added new intrinsic to llvm/include/llvm/TCEInstrinsics.td: def int_tce_customop : Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_vararg_ty], [],

Hi All, While compiling libgcc with LLVM for our target, it seems I don't get __builtin_dwarf_cfa() right. That causes uw_init_context_1 [1] initialize the wrong context, and the overall exception handling fail. I find Hal provided patch years ago adding ISD::EH_DWARF_CFA, which corresponding to __builtin_dwarf_cfa(), and let us have the opportunity to handle __builtin_dwarf_cfa() for our

Chris, > That's an easy problem. I just implemented __builtin_return_address > on PPC, at least builtin_return_address(0), please let me know if that > is sufficient. There are bunch of another builtins required for eh to execute properly. The 3 most important one are: - eh_return - unwind_init - dwarf_cfa The first two precisely match to the gcc's ones, the third - slightly

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > On Mon, 5 Feb 2007, Dan Gohman wrote: > > > LLVM knows what all the types of the intrinsic functions are; I thought, > > why are users (including llvm-gcc...) required to duplicate all this > > information in order to use them? I mean in order to call > > getOrInsertFunction to get declarations for

Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes: >> -----Original Message----- >> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David Greene >> via llvm-dev >> Sent: Thursday, August 29, 2019 10:05 AM >> To: llvm-dev <llvm-dev at lists.llvm.org> >> Subject: [EXT] [llvm-dev] Complex proposal v2 >>

Hi, When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes only from memory that one of its arguments points to, but may access an unspecified amount." "If no property is set,

I have friendship data which is strong skewed. So it doesn't make sense to use maximum likelihood methods for fa and cfa. But I couldn't find any function for asymptotically distributed data for doing a factor analysis. Only: apca() but there is no possibility to allow for factor correlations. The same problem is with sem() I couldn't get any solutions for my model because of the

Hello, I am trying to do a multiple groups CFA in lavaan and I get the following error message: Error in cov(data.obs, use = "pairwise") : 'x' is empty I'm not sure what this message is referring to, can anyone help me? Thanks -- View this message in context: http://r.789695.n4.nabble.com/Multiple-Groups-CFA-in-Lavaan-tp3457971p3457971.html Sent from the R help mailing