similar to: [LLVMdev] Question about variable sized arrays

Renato Golin <renato.golin at arm.com> writes: > Example: > > // CHECK: %struct.I = type { i32, i8 } > struct I { > int a; > char b; > }; > > // CHECK: %struct.J = type { [8 x i8], i8, [3 x i8] } > struct J : I { > char c; > }; > > What happens here is that "c" is placed in the base's tail padding and > there are three bytes

On 08/26/2011 05:32, Stephan Falke wrote: > As stated in LLVM's language reference manual > (http://llvm.org/docs/LangRef.html#i_shl), both arguments for a shl need > to have the same type. In my case, original types were uint8 (value) and uint32 (shift) llvm lacks unsigned types which made it S1=i8 and S2=i32. It's technically nothing wrong with such combination, and code works

Hi, I've read http://llvm.org/docs/LangRef.html#t_array and http://llvm.org/docs/GetElementPtr.html and if I've understood right there are no operations that act directly on arrays - instead I need to use getelementptr on a pointer to an array to get a pointer to an array element. I also understand that there is no 'address of' operation. As a result I can't figure out how to

2010/1/11 Eli Friedman <eli.friedman at gmail.com> > On Mon, Jan 11, 2010 at 7:07 AM, James Williams <junk at giantblob.com> > wrote: > > Hi, > > > > I've read http://llvm.org/docs/LangRef.html#t_array and > > http://llvm.org/docs/GetElementPtr.html and if I've understood right > there > > are no operations that act directly on arrays -

On Mon, Jan 11, 2010 at 7:07 AM, James Williams <junk at giantblob.com> wrote: > Hi, > > I've read http://llvm.org/docs/LangRef.html#t_array and > http://llvm.org/docs/GetElementPtr.html and if I've understood right there > are no operations that act directly on arrays - instead I need to use > getelementptr on a pointer to an array to get a pointer to an array

2010/1/11 Garrison Venn <gvenn.cfe.dev at gmail.com> > I have not tried this, but a linkage type of PrivateLinkage would not add > to the symbol table according > to the doc. > > LLVMSetLinkage(g, LLVMPrivateLinkage); > Thanks - I hadn't thought of that. > > Garrison > > On Jan 11, 2010, at 14:03, James Williams wrote: > > 2010/1/11 Eli Friedman

I have not tried this, but a linkage type of PrivateLinkage would not add to the symbol table according to the doc. LLVMSetLinkage(g, LLVMPrivateLinkage); Garrison On Jan 11, 2010, at 14:03, James Williams wrote: > 2010/1/11 Eli Friedman <eli.friedman at gmail.com> > On Mon, Jan 11, 2010 at 7:07 AM, James Williams <junk at giantblob.com> wrote: > > Hi, > > >

Does the C API have an equivalent of stack storage? Via the C++ APIs one can shove the string constant on the stack via a store instruction operation on an alloca instruction--the address needed is the alloca. For example: llvm::Value* stringVar = builder.CreateAlloca(stringConstant->getType()); builder.CreateStore(stringConstant, stringVar); The stringVar is your address. Garrison On Jan

Sorry to keep this thread alive, but I'm learning so ... There is more. The doc for GlobalValue::LinkageTypes or the C API LLVMLinkage is not as clear as the lang ref manual. See: http://llvm.org/docs/LangRef.html#linkage. I'm pointing this out because something like LinkerPrivateLinkage (LLVMLinkerPrivateLinkage), or another one, might be more appropriate to your throw away use case (if

Hi Duncan, On 11/10/12 15:47, Duncan Sands wrote: > Hi Roel, > >> When going through the internals of the old C back-end, I see that the CBE >> encapsulates arrays into a struct. The source code has the following comment to >> explain this behaviour. >> >> // Arrays are wrapped in structs to allow them to have normal >> // value semantics

Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK:

Chars don't exist in LLVM. Clang may map char to be i8, but LLVM doesn't know the difference. Joey On 17 April 2012 00:14, Ryan Taylor <ryta1203 at gmail.com> wrote: > Bill, > > Thanks, yes, I realize that's not what it's for; however, it looks like > with a little tweaking it would be possible but I'd rather not change the > LLVM base code. Guess

Hi Roel, > When going through the internals of the old C back-end, I see that the CBE > encapsulates arrays into a struct. The source code has the following comment to > explain this behaviour. > > // Arrays are wrapped in structs to allow them to have normal > // value semantics (avoiding the array "decay"). > > For example, the CBE translates: >

On 15 February 2011 18:30, David A. Greene <greened at obbligato.org> wrote: > { int32, int8, { int8 } } > > Do I understand you correctly? Hi David, I'm actually looking for answers, not requesting features... ;) That structure would actually solve the problem for this specific case, but not for the general case. There are far too many exceptions to be worth make a special

Right, they are identifiers. Storing them as String has drawbacks: - huge to store in memory - slow to process - huge to index (by eg data.table columns indexes) Why not storing them as numeric ? Thanks, Le 20 janv. 2017 ? 18h16, William Dunlap ?crivait : > If these are identifiers, store them as strings. If not, what sort of > calculations do you plan on doing with them? > Bill

Hi, Intel Advanced Matrix Extensions (Intel AMX) is a new programming paradigm consisting of two components: a set of 2-dimensional registers (tiles) representing sub-arrays from a larger 2-dimensional memory image, and accelerators able to operate on tiles. Capability of Intel AMX implementation is enumerated by palettes. Two palettes are supported: palette 0 represents the initialized state and

Hello all, According to *clang/lib/CodeGen/CodeGenFunction.cpp*, a LLVM annotation intrinsic call has 4 arguments: - llvm::Value *AnnotatedVal, - Builder.CreateBitCast(CGM.EmitAnnotationString(AnnotationStr), Int8PtrTy), - Builder.CreateBitCast(CGM.EmitAnnotationUnit(Location), Int8PtrTy), - CGM.EmitAnnotationLineNo(Location) However, this is what an annotation intrinsic *char

Hello r users, I have to deal with int8 data with R. AFAIK R does only handle int4 with `as.integer` function [1]. I wonder: 1. what is the better approach to handle int8 ? `as.character` ? `as.numeric` ? 2. is there any plan to handle int8 in the future ? As you might know, int4 is to small to deal with earth population right now. Thanks for you ideas, int8 eg: human_id

Hello all, When going through the internals of the old C back-end, I see that the CBE encapsulates arrays into a struct. The source code has the following comment to explain this behaviour. // Arrays are wrapped in structs to allow them to have normal // value semantics (avoiding the array "decay"). For example, the CBE translates: @a = common global [10 x i32]

Well I definitely cannot use them as numeric because join is the main reason of those identifiers. About int64 and bit64 packages, it's not a solution, because I am releasing a dataset for external users. I cannot ask them to install a package in order to exploit them. I have to be very carefull when releasing the data. If a user just use read.csv functions, they by default cast the