Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] Integer handling"
2008 Sep 29
0
[LLVMdev] Integer handling
On Mon, Sep 29, 2008 at 12:41 AM, OvermindDL1 <overminddl1 at gmail.com> wrote:
> I have ended up making a rather complicated type system to handle
> quite a few things, all stemming from the fact that the integer type
> has no sign information (even if it did not use it, would be nice to
> look at it in my code generator to so I can put out one function type
> [snip]
Hi, I
2008 Sep 29
2
[LLVMdev] Integer handling
On Sep 29, 2008, at 1:29 PM, Scott Graham wrote:
> On Mon, Sep 29, 2008 at 12:41 AM, OvermindDL1
> <overminddl1 at gmail.com> wrote:
>> I have ended up making a rather complicated type system to handle
>> quite a few things, all stemming from the fact that the integer type
>> has no sign information (even if it did not use it, would be nice to
>> look at it in
2008 Sep 29
0
[LLVMdev] Integer handling
I know why it was removed, and it does make sense, just would be nice
if there was an option to be able to get two pointer to a specific
llvm::IntegerType, functionally they would be identical, but for user
code (hence, my code) would be useful as I could match it for the
different ones at generate different code for each.
With some discussion with others I think we came up with an acceptable
2009 Dec 06
0
[LLVMdev] Fwd: Adding multiples-of-8 integer types to MVT
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
2008 Sep 09
2
[LLVMdev] Integer questions
Do note though, that would cause an interface breaking change (just in
the function signatures, but still). An alternate would be to just
pass in a struct that the user can subclass to perform their own error
reporting, call a certain function in it or so before it finally bails
out, it puts a level of indirection so if someone wants to recover
they will have to use their own variables stored
2008 Sep 05
3
[LLVMdev] Integer questions
First off, most of my information about the integer representation in
LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could
use some things cleared up.
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).
What if someone made an i4 and compiled it on 32/64 bit
windows/nix/bsd
2016 Sep 27
2
SelectionDAG::LegalizeTypes is very slow in 3.1 version
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
2008 Sep 09
0
[LLVMdev] Integer questions
> Patches to do the kind of checking you're asking about would be
> welcome :-). I don't think it makes sense to extend the
> Verifier itself here; it's supposed to accept any valid LLVM IR.
> I think a separate CodeGenVerifier might be a good approach
> though, or possibly extending codegen itself with the ability to
> interrupt itself and yield some kind of error
2008 Sep 09
2
[LLVMdev] Integer questions
On Sep 8, 2008, at 4:30 PM, OvermindDL1 wrote:
>> The Verifier pass is recommended; it catches a lot of
>> invalid stuff and be configured to abort, print an error to
>> stderr, or return an error status and message string.
>>
>> It doesn't catch everything though; codegen's error
>> handling today is usually an assertion failure, assuming
>>
2009 Dec 02
11
[LLVMdev] Adding multiples-of-8 integer types to MVT
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-,
2008 Sep 30
2
[LLVMdev] Integer handling
OvermindDL1 wrote:
>
> I know why it was removed, and it does make sense, just would be nice
> if there was an option to be able to get two pointer to a specific
> llvm::IntegerType, functionally they would be identical, but for user
> code (hence, my code) would be useful as I could match it for the
> different ones at generate different code for each.
>
Well a language
2008 Mar 26
2
[LLVMdev] Checked arithmetic
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
2010 Nov 23
1
[LLVMdev] Unrolling loops into constant-time expressions
Hello,
I've come across another example:
I'm compiling with
clang -S -emit-llvm -std=gnu99 -O3
clang version 2.9 (trunk 118238)
Target: x86_64-unknown-linux-gnu
Thread model: posix
I take the code:
int loops(int x) {
int ret = 0;
for(int i = 0; i < x; i++) {
for(int j = 0; j < x; j++) {
ret += 1;
}
}
return ret;
}
and the
2009 Dec 12
1
[LLVMdev] Adding multiples-of-8 integer types to MVT
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
2012 Aug 17
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
On Thu, Aug 16, 2012 at 11:48 PM, Fabian Scheler
<fabian.scheler at gmail.com> wrote:
> Hi Eli,
>
> thank you for the information.
>
>>> thanks to kind help of the LLVM-community I was able to bring my
>>> TriCore back-end a huge step forward, however I am not done, so far. I
>>> still miss the following features and maybe you could again provide me
2008 Mar 26
0
[LLVMdev] Checked arithmetic
On Wed, 26 Mar 2008, Duncan Sands wrote:
> 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
The desired code is something like:
foo:
addl %eax, %ecx
jo
2012 Aug 17
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
Hi Eli,
thank you for the information.
>> thanks to kind help of the LLVM-community I was able to bring my
>> TriCore back-end a huge step forward, however I am not done, so far. I
>> still miss the following features and maybe you could again provide me
>> some help:
>>
>> 1. Passing return values on the stack
>>
>> Describing the calling
2008 Sep 30
0
[LLVMdev] Integer handling
On Mon, Sep 29, 2008 at 8:49 PM, Matt Giuca <mattgiuca at gmail.com> wrote:
> /* snip */
The language I am making is not a traditional scripting language, it
is designed for heavy math work. It has not classes, the basic data
structure is a struct, yet even those are only used to pass messages.
It is using the Actor-Oriented model, not Object-Oriented. I have
been creating it to deal
2010 Nov 07
0
[LLVMdev] Hoisting elements of array argument into registers
David Peixotto <dmp <at> rice.edu> writes:
> I am seeing the wf loop get optimized just fine with llvm 2.8 (and almost
as good with head).
I rechecked this and am I actually seeing the same results as you. I think I
must have made a stupid mistake in my tests before - sorry for the noise.
However, I found that we have a phase ordering problem which is preventing us
getting as much
2014 Oct 24
2
[LLVMdev] Virtual register def doesn't dominate all uses
Hi!
During my backend development I get the error message for some tests:
*** Bad machine code: Virtual register def doesn't dominate all uses. ***
(C source-code, byte-code disassembly and printed machine code at the end of the email)
The first USE of vreg4 in BB#1 has no previous DEF in BB#0 or #1. But why? I can't see how the LLVM byte-code is transformed to the lower machine code.