similar to: [LLVMdev] Please review the 2.5 release notes

> Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html The description of nocapture is a bit funny: "... pointer arguments to functions that access through but do not return the pointer in a data structure that out lives the call" I think it needs s/return/retain/ and s/out lives/outlives/ > In addition, many APIs have changed in this release. Some

Chris Lattner wrote: > Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html Here are two typos I noticed: s/improvmenets/improvements/ s/GFortan/GFortran/ -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

Hello, I'm trying to compile vmkit on a x86_64 linux box with gcc-4.1.2, but I'm running into troubles because of various problems with casts between pointers and integers. Is there anybody who succeeded in this task? Az I see, some of the problems can be fixed with an appropriate typedef/macro declaration, but in VMCore/JavaObject.cpp some lowlevel bitmanipulation is used, to mark

Neil Booth wrote: > Talin wrote:- > >> On the other hand, writing an interpreter means duplicating a lot of >> the functionality that's already in LLVM. For example, consider just >> the problem of float to int conversions: >> >> char B[ (int)3.0 ]; >> >> Generating code for this is relatively simple; Converting >> arbitrary-sized

Talin wrote:- > Well, I may be using it wrong. But looking at APFloat.h, I see four > functions that purport to convert to integer: > > opStatus convertToInteger(integerPart *, unsigned int, bool, > roundingMode) const; > opStatus convertFromSignExtendedInteger(const integerPart *, > unsigned int, >

Hi Zsombor, Thanks for the patch! Unfortunately I can't apply it because the llvm API has moved from BinaryOperator::create to BinaryOperator::Create. Are you using svn head? Now on the x86_64 part. There has been very little work on porting vmkit on x86_64. If you're having compilation problems, I suppose it's in the garbage collector directory (GCMmap2). If you could make the

Hi any, Can some please detail me the createX command in bayesm package? To make things easy for you to help me, let me put forward my problem Suppose I have 3 covariates (say X matrix) and my Y has 3 categories say (1,2,3). Now from the CreateX I understand that the data matrix say 'Xa' must be of dimension n* (naxp), where 'na' is the number of variables and 'p' is

Hello, I have a small problem with developing design matrix X, which I use in estimation the log-likelihood of a multinomial logit model. I have the data: number of observation - 289 number of choice alternative- 3 number of choice specific variables in matrix X -4 matrix X =289x4 I tried to use the function createX, I know that I have to get design matrix 289x12 (am I right?) but

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 >>

How are bitfields handled in StructLayout? In LLVM 2.5 the struct is unambiguously size by: StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data In LLVM 2.6 it's getTypeAllocSize, which does the same thing. Unfortunately, this is not correct for bitfields. For example, LLVM reports this struct: typedef struct test1 { short f0 : 10; char f1 : 5; long f2 : 1;

Hi, I want to compute the bitwise 'and' between two values of type int1:  %x = and %a, %b  . Which is the LLVM instruction that creates this? I only found the APInt class, whose constructor is:  APInt(unsigned numBits, uint64_t val, bool isSigned = false) and which provides the bitwise AND operation: APInt  llvm::APIntOps::And (const APInt &LHS, const APInt &RHS)   Bitwise

What is the proper way to get the bit pattern associated with a ConstantFP? The 32 bit pattern if MVT::f32 or pair of 32 bit patterns with MVT::f64 ? Tia. Reed

> Another very annoying fact is that the Clang driver re-parses triples many > times, and sometimes they change the triple based on a CPU, and then end > up with a different CPU. I’ve recently been tasked with cleaning this up. Before starting on this full gusto, I want to make sure I’m not stepping on any toes or duplicating work. The rough plan is as follows; 1. Replace the call to

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

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 been revising some FORTRAN 77 routines in R packages I have previously submitted. Since R is now using gfortan I experimented with some Fortran 90 code (array intrinsics primarily). So far the code is still in F77 fixed format, in files suffixed .f (not .f90), but incorporates some F90 constructs. It has worked fine in linux/R. I tried to follow the thread of previous discussions

SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP ().bitcastToAPInt (); I can't easily override this in target specific code. Can anyone see an issue with submitting the patch to upstream? Suggestions for an in tree target that could trigger this would be very welcome. Cheers -------------- next part

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! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc: