Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] GEPping GEPs and first-class structs"
2009 Feb 02
0
[LLVMdev] GEPping GEPs and first-class structs
On Feb 1, 2009, at 5:38 AM, Jon Harrop wrote:
>
> As I understand it, first-class structs will allow structs to be
> passed as
first-class structs already exist. :)
>
> function arguments and returned as results (i.e. multiple return
> values)
> instead of passing pointers to structs. However, the GEP instruction
> only
> handles pointer types. So I do not
2009 Feb 02
0
[LLVMdev] GEPping GEPs and first-class structs
Hi Jon, check out
http://llvm.org/docs/LangRef.html#aggregateops
Ciao,
Duncan.
2009 Nov 25
3
[LLVMdev] Possible bug in TCO?
My compiler is generating a bunch of code including the following line:
%57 = call fastcc i32 @aux(%1* %0, %1 %1, %1 %46, i32 0, %4 %2) ; <i32>
[#uses=1]
ret i32 %57
The program works fine as long as this isn't a tail call. If I compile via
a .ll and insert "tail" by hand, the program segfaults. However, if I make it
a tail call and return an undef i8* or void instead
2009 Feb 19
6
[LLVMdev] Improving performance with optimization passes
I'm toying with benchmarks on my HLVM and am unable to get any performance
improvement from optimization passes. Moreover, some of my programs generate
a lot of redundant code (e.g. alloca a struct, store a struct into it and
read only one field without using the rest of the struct) and this does not
appear to be optimized away.
I simply copied the use of PassManager from the Kaleidoscope
2010 Jul 13
1
[LLVMdev] const indices of extractvalue
Hi,
The 'extractvalue' and 'insertvalue' instructions only allow constant
indices. If I have an array with variable indices, I need to store
it into memory, and then load its sub-elements via GEP. Why could
'extractvalue' not support variable indices like GEP? In general, in
which case should source code be translated into 'extractvalue' , and
when should
2009 Feb 19
0
[LLVMdev] Improving performance with optimization passes
Hi Jon,
On 2009-02-19, at 14:00, Jon Harrop wrote:
> I'm toying with benchmarks on my HLVM and am unable to get any
> performance improvement from optimization passes. I simply copied
> the use of PassManager from the Kaleidoscope tutorial:
>
> Any idea what I might be doing wrong? Has anyone else got this
> functionality giving performance boosts from OCaml?
2009 Nov 29
0
[LLVMdev] JVM Backend
On Sunday 29 November 2009 02:06:04 you wrote:
> > So it will stack overflow on tail calls
>
> At the moment, yes. But then again, so does java.
Sure but a lot of people like me are using LLVM precisely because it offers
these wonderful features. As long as your JVM backend does not handle these
features correctly its utility is greatly diminished.
> Also, it looks like
2009 Feb 19
0
[LLVMdev] Improving performance with optimization passes
On Thursday 19 February 2009 19:00:14 Jon Harrop wrote:
> I'm toying with benchmarks on my HLVM and am unable to get any performance
> improvement from optimization passes...
I just disassembled some of the IR before and after optimization. This example
function squares a complex number:
let zsqr(r, i) = (r*r - i*i, 2*r*i)
My compiler is generating:
define fastcc i32 @zsqr({
2009 Nov 29
5
[LLVMdev] JVM Backend
> So it will stack overflow on tail calls
At the moment, yes. But then again, so does java. Also, it looks like
they're working on support for tail calls in the Da Vinci Machine[1].
> and break with run-time errors
When I said it raises an assertion, I meant at compile-time.
> on structs?
No, structs are supported. The only unsupported types at the moment
(as far as I am aware) are
2017 Jan 02
2
Indices for extractvalue and insertvalue
Hi
Can someone explain to me why we cant use uint64_t for extractvalue
and insertvalue indices, while GEP on arrays can have indices of any
integer type. Basically if I load an array with UINT_MAX+O (O>=2)
elements, I can not extract its last element.
Given this restriction I feel we have a bug here (uint64_t is passed
as a unsigned). This cant happen because of the if (NumElements >
1024)
2009 Feb 19
1
[LLVMdev] Improving performance with optimization passes
On Thursday 19 February 2009 19:32:14 Gordon Henriksen wrote:
> Hi Jon,
>
> On 2009-02-19, at 14:00, Jon Harrop wrote:
> > I'm toying with benchmarks on my HLVM and am unable to get any
> > performance improvement from optimization passes. I simply copied
> > the use of PassManager from the Kaleidoscope tutorial:
> >
> > Any idea what I might be doing
2008 Jun 02
2
[LLVMdev] Plans considering first class structs and multiple return values
Hi Dan,
> Yes, the intention is that getresult will be removed once first-class
> aggregates are a ready replacement. This won't leave LLVM missing the
> concept of returning multiple values; a struct can be thought of as
> a container for multiple values.
I'm not saying we don't have some way of modeling multiple return values, I'm
sayin the explicit concept
2015 Jan 22
2
[LLVMdev] Another struct-return question
On 01/20/2015 12:45 PM, Reid Kleckner wrote:
> On Tue, Jan 20, 2015 at 9:52 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote:
>
> 1) Larger structs are returned differently, via memcpy. Do
> these methods of returning struct values show through in
> the ultimately generated machine code? It seems hard to
2008 Jun 02
0
[LLVMdev] Plans considering first class structs and multiple return values
On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote:
> Hi Dan,
>
>> Yes, the intention is that getresult will be removed once first-class
>> aggregates are a ready replacement. This won't leave LLVM missing the
>> concept of returning multiple values; a struct can be thought of as
>> a container for multiple values.
> I'm not saying we don't have some
2009 Feb 19
1
[LLVMdev] Improving performance with optimization passes
>
> On Thursday 19 February 2009 19:00:14 Jon Harrop wrote:
>> I'm toying with benchmarks on my HLVM and am unable to get any
>> performance
>> improvement from optimization passes...
>
> I just disassembled some of the IR before and after optimization.
> This example
> function squares a complex number:
Something is definitely wrong with the way
2010 Jan 13
7
[LLVMdev] [PATCH] - Union types, attempt 2
Here is the LangRef part of the patch.
On Tue, Jan 12, 2010 at 2:11 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Jan 11, 2010, at 4:30 PM, Talin wrote:
>
> I'm working on a new version of the patch.
>>
>> Another thing I wanted to ask about - do you prefer to have one giant
>> patch that has everything, or a series of incremental patches? I can
2010 Jan 13
0
[LLVMdev] [PATCH] - Union types, attempt 2
On Jan 12, 2010, at 5:01 PM, Talin wrote:
> Here is the LangRef part of the patch.
> +<p>The union type is used to represent a set of possible data types which can
> + exist at a given location in memory (also known as an "untagged"
> + union).
[...]
This wording is somewhat misleading; memory in LLVM has no types.
How about:
"A union type describes an
2008 Jun 02
2
[LLVMdev] Plans considering first class structs and multiple return values
Hi Dan,
> The requirement to update all callers' call instructions when a callee
> gets a new return value is also present in the current MRV-mechanism
> with getresult. It's not been a problem we've worried about so far.
I didn't mean you can get away without updating your calllers, I'm just saying
it could be a bit easier.
> Can you give some background about
2013 Mar 30
2
[LLVMdev] Missed optimisation opportunities?
I'm writing a front end for an existing interpreted language with slightly
odd semantics for primitive values.
Similar to the values in a database table, any value could be null, even
for non-pointer types.
For example a boolean variable could be true, false, or null.
To model this behaviour, I'm passing an {i1, [type]} around for every
numeric type. And using insertvalue / extractvalue
2008 May 30
0
[LLVMdev] Plans considering first class structs and multiple return values
On May 30, 2008, at 9:11 AM, Matthijs Kooijman wrote:
> Hi all,
>
> I've been implementing some stuff that uses the new structs-as-
> firstclass
> values code. Apart from some implementation problems, I'm spotting a
> few
> structural problems that seem non-trivial to fix.
Hi, thanks for your interest!
> Furthermore, as far as I've understood, the