similar to: [LLVMdev] 40-bit integer registers

>> Would there be any interest/opposition to extending the set of simple >> integer types in MVT to include the missing multiples of 8 (up to 64 >> bits)? That is: i24, i40, i48, i56? By the way, the integer type legalization logic should probably go like this: let T be an integer type. (1) If T is legal, do nothing. (2) If there is a legal integer type which is bigger (in

On Saturday, December 05, 2009 7:34 AM, Duncan Sands wrote, > > >> Would there be any interest/opposition to extending the > set of simple > >> integer types in MVT to include the missing multiples of 8 > (up to 64 > >> bits)? That is: i24, i40, i48, i56? > > By the way, the integer type legalization logic should > probably go like > this: let

Hi Ken, > Would there be any interest/opposition to extending the set of simple > integer types in MVT to include the missing multiples of 8 (up to 64 > bits)? That is: i24, i40, i48, i56? the type legalizer would need some work. Consider an architecture which has a 24 bit register. Then the type legalizer should legalize an i40 by first promoting it to an i48, then expanding that to

Would there be any interest/opposition to extending the set of simple integer types in MVT to include the missing multiples of 8 (up to 64 bits)? That is: i24, i40, i48, i56? Adding the types to MVT (and ValueTypes.td) would allow LLVM to be targeted to architectures that have registers and operations of these sizes (for example, a 24-bit DSP that I'd like to develop a back end for has 24-,

Hi Ken, > What would do you think of modifying case (3) slightly as follows? well, that special cases the smallest legal type, which might not be a good idea. Imagine that i10 is legal, and also i32. Is it better to turn i40 into four lots of i10 or two lots of i32 with a promotion? Expansion is expensive, so two lots of i32 would be best. I suggest the following scheme: (3) Suppose T is

Grr... ---------- Forwarded message ---------- From: OvermindDL1 <overminddl1 at gmail.com> Date: Sat, Dec 5, 2009 at 5:58 PM Subject: Re: [LLVMdev] Adding multiples-of-8 integer types to MVT To: Duncan Sands <duncan.sands at math.u-psud.fr> On Sat, Dec 5, 2009 at 5:33 AM, Duncan Sands <duncan.sands at math.u-psud.fr> wrote: >>> Would there be any interest/opposition

Hi Chris, > Why not define an "add with overflow" intrinsic that returns its value and > overflow bit as an i1? what's the point? We have this today with apint codegen (if you turn on LegalizeTypes). For example, this function define i1 @cc(i32 %x, i32 %y) { %xx = zext i32 %x to i33 %yy = zext i32 %y to i33 %s = add i33 %xx, %yy %tmp = lshr i33 %s, 32 %b = trunc

In 3.1, the backend is very slow to legalize types. Following is the code snippet which may be the culprit: %Result.i.i.i97 = alloca i33, align 8 %Result.i.i.i96= alloca i33, align 8 %Result.i.i.i95 = alloca i33, align 8 %Result.i.i.i94 = alloca i33, align 8 %Result.i.i.i93 = alloca i33, align 8 %Result.i.i.i92= alloca i33, align 8 %Result.i.i.i91 = alloca i33, align 8

On Tue, 2008-03-25 at 21:18 -0700, Chris Lattner wrote: > On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > > > In looking at the LLVM reference manual, it is conspicuous that (a) > > the > > IR does not define condition codes, and (b) the IR does not define > > opcodes that return condition results in addition to their > > computational > >

Hi all, hope someone can help me out with this. Background Introduction I have a data set consisting of data collected from a questionnaire that I wish to validate. I have chosen to use confirmatory factor analysis to analyse this data set. Instrument The instrument consists of 11 subscales. There is a total of 68 items in the 11 subscales. Each item is scored on an integer scale between 1 to 4.

Hi. I am beginning to learn LLVM (using LLVM 2.3.0 on a Linux x86_64 machine) and wanted to check the status of the support of arbitrary size integers. To do so, I tried to modify the HowToUseJIT example by replacing the Int32Ty with another size (let's say 12 bits for the example). While it compiles ok, I get the following assert at run-time: HowToUseJIT: LegalizeDAG.cpp:4059:

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > I want to background process this for a bit, but it would be helpful to > discuss some approaches first. > > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions

On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote: > Would there be any interest/opposition to extending the set of simple > integer types in MVT to include the missing multiples of 8 (up to 64 > bits)? That is: i24, i40, i48, i56? > > Adding the types to MVT (and ValueTypes.td) would allow LLVM to be > targeted to architectures that have registers and operations of these > sizes

On Wednesday, December 02, 2009 7:09 PM, Chris Lattner wrote: > > On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote: > > > Would there be any interest/opposition to extending the set > of simple > > integer types in MVT to include the missing multiples of 8 > (up to 64 > > bits)? That is: i24, i40, i48, i56? > > > > Adding the types to MVT (and

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

> Please start a thread on llvmdev about this functionality, and outline what other intrinsics will have to change to add non-8-bit byte support. Well, memset is the only we have seen so far (our back-end is ~50% finished for an initial release). We have our own front-end as well (we are currently not using the clang front-end), and currently don't use many llvm intrinsics (only

Duncan, here is part of the assembly around the problem area. I used gcc -S -flto to generate the .s file, llvm-as on the .s fiile will show error: invalid cast opcode for cast from 'i40' to 'float' %638 = trunc i40 %637 to float %633 = bitcast i8* %632 to float* %634 = bitcast float* %633 to i40* %635 = load i40* %634, align 1 %636 = shl i40 %635, 7 %637 = ashr i40

Hi ZY, On 11/05/13 22:21, Zhiyuan Ren wrote: > Duncan, > > here is part of the assembly around the problem area. I used gcc -S -flto to > generate the .s file, llvm-as on the .s fiile will show error: invalid cast > opcode for cast from 'i40' to 'float' %638 = trunc i40 %637 to float > > %633 = bitcast i8* %632 to float* > %634 = bitcast float* %633 to

Here is a series of patches replacing EVT with MVT at a number of places in TargetLowering. The last two patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change

On Sep 23, 2011, at 1:38 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> It appears that tablegen is inferring the 'type' of an individual >> register by enumerating all the register classes it appears in. Some >> things, like using implicit defs in SDNodes, only works for registers >> with a unique type. My