similar to: [LLVMdev] Integer questions

Hi, > First, I guess that smaller integer sizes, say, i1 (boolean) are > stuffed into a full word size for the cpu it is compiled on (so 8bits, > or 32 bits or whatever). on x86-32, an i1 gets placed in an 8 bit register. > What if someone made an i4 and compiled it on 32/64 bit > windows/nix/bsd on a standard x86 or x64 system, and they set the > value to 15 (the max size of

Hi everyone! Here, I have a question and am curious about i128. I want to know how the LLVM handle i128, because many compiler backend doesn't support i128 directly. So I am very curious and want to how the llvm handle this situation? Besides i128, such as i256, i512, even i24? Thanks. Best Regards Wu Zhao -------------- next part -------------- An HTML attachment was scrubbed...

On Sep 5, 2008, at 3:07 PM, Duncan Sands wrote: > The current maximum the code generators support is i256. If you try > to > use bigger integers it will work fine in the bitcode, but if you try > to do code generation the compiler will crash. FYI, there is one other issue here, PR2660. While codegen in general can handle types like i256, individual targets don't always have

On Mon, Sep 8, 2008 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: > FYI, there is one other issue here, PR2660. While codegen in > general can handle types like i256, individual targets don't always > have calling convention rules to cover them. For example, returning > an i128 on x86-32 or an i256 on x86-64 doesn't doesn't fit in the > registers designated

On 10/20/2016 9:28 AM, Cameron McInally via llvm-dev wrote: > I should have attached the generated asm to save some trouble. > Apologies for that and attaching now... > > > > On Thu, Oct 20, 2016 at 12:26 PM, Cameron McInally > <cameron.mcinally at nyu.edu> wrote: >> On Thu, Oct 20, 2016 at 12:05 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

Hi everyone. After lurking for a while, this is my first post to the list. I am working with some graduate students on the general topic of compiler support for SIMD programming and specific projects related to LLVM and my own Parabix technology (parabix.costar.sfu.ca). Right now we have a few course projects on the go and already a question arising out of one of them (SSE2 Hoisting).

On Thu, Oct 20, 2016 at 12:05 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Oct 20, 2016, at 8:54 AM, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hey guys, >> >> I've hit a pretty nasty issue on SKX with ANDs of masks <= 4 bits. >> >> In the IR, we represent a 4b vector mask as <4 x i1>.

*Problem-1* CASE-I---------(works fine) > var1<-"tom" > var1 [1"tom" > var1<-as.character(var1) > var1 [1] "tom" > var2<-c("tom","harry","kate") > logc<-(var1 %in% var2) > logc [1] TRUE > typeof(var1) [1] "character" > typeof(var2) [1] "character"

I have dataframe with 17factors variables (for example every factor have 3levels) I have maybe 5000 observation. And i need to do table where is in every raw 1 of possible combination of this factors and the numbur how many time is this combination in my dataset. I wrote one code, but this is very slow and dumb. it looks like this: i<-0 for(i1 in levels(hivdat$pohl)){

Hi Jianzhou, > I misunderstood C99 ISO, such behaviors are defined not when types > have the same sizes, but when they are same (compatible) types with > signed or qualified extension (this is much stronger than being of > same sizes), or reading char by char: > > 7 An object shall have its stored value accessed only by an lvalue > expression that has one of > the

Hi LLVM, 1. Can mul and/or div support be added for big integer types like i256? 2. What are the limits? 3. If yes, how should it be done? I have experience only with X86 target and know that mul i128 works and div i128 is lowered to function call from compile-rt like library (what works only if you link with such library). Can that support be extended? - Paweł -------------- next part

Hello List, I am on the hook to instrument a piece of legacy LLVM IR code, and then we are planning to feed to the SeaHorn framework for some model checking tasks. After the instrumentation, I tried to use llc (version 3.9) to compile the IR code, and it works fine. However, when I try to use llc (version 3.8.1, the default llvm version of SeaHorn) to compile the IR code, it shows the following

On 20 October 2010 06:22, Jin Gu Kang <jaykang10 at imrc.kist.re.kr> wrote: > The IR in an previous e-mail is incomplete so far and > I am converting it to various shape. Hi Jin, No worries. I'm interested in the outcome, so I'm playing the devil's advocate to make sure your proposal is consistent with the rest of LLVM. > %Char = type { c3, c4, c3, c2 } > %Short =

Hi all, Can anyone suggest me how to insert rows in between data frames and also keep the ordering of row numbers correct? Estimate Std. Error t value Pr(>|t|) recmeanC2 9.275880e-17 6.322780e-17 1.467057e+00 0.14349903 recmeanC3 1.283534e-17 2.080644e-17 6.168929e-01 0.53781390

Hi, Following is excerpted from http://llvm.org/releases/3.1/docs/LangRef.html#int_ctpop. How come the return type needs to be consistent with parameter type? i64/i128 seems to be overkill, and i8, i16 are inconvenient. ----------------------------------- declare i8 @llvm.ctpop.i8(i8 <src>) declare i16 @llvm.ctpop.i16(i16 <src>) declare i32 @llvm.ctpop.i32(i32

Hi renato, First, I really appreciate your answer. :) The IR in an previous e-mail is incomplete so far and I am converting it to various shape. My team members decided to add new types to solve the bitfield's alignment problem. Let's consider your previous examples: struct testChar { char a:3; char b:4; char c:3; char d:2; }; struct testShort { short a:3; short b:4; short c:3;

On Fri, Jul 9, 2010 at 3:44 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jianzhou, > >> I misunderstood C99 ISO, such behaviors are defined not when types >> have the same sizes, but when they are same (compatible)  types with >> signed or qualified extension (this is much stronger than being of >> same sizes), or reading char by char: >> >> 7

Hello all I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. Best Ehsan Input File: target datalayout =

Hi Renato, Firstly, I have been removing target specific information from struct type on bitcode. Target specific information are type size, type alignment, merged bitfields and so on. For example 1 struct test { 2 char a:3; 3 char b:4; 4 char c:3; 5 char d:2; 6 }; 7 8 struct test vm = {1, 2, 3, 1}; 9 10 int main(void) 11 { 12 int a; 13 vm.d = 1; 14 } Above

How to NATURAL sort a vector or data frame* by row* , in ascending order ? V1 V2 V3 V4 i1 5.000000e-01 1.036197e-17 4.825338e+16 0.00000000 i10 4.001692e-18 1.365740e-17 2.930053e-01 0.76973827 i12 -1.052843e-17 1.324484e-17 -7.949081e-01 0.42735000 i13 2.571236e-17 1.357336e-17 1.894325e+00 0.05922715 i2