Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] LLI Segfaulting"
2012 Mar 12
2
[LLVMdev] LLI Segfaulting
Hi Duncan,
Duncan Sands wrote:
>
> Hi Fraser, it looks to me like you are smashing the stack.
>
>> define void @main() nounwind {
>> allocas:
>> %0 = alloca { i32, [0 x i32] }, align 8
>
> ^ this allocates 4 bytes on the stack.
>
>> %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1
>
> ^ this gets a pointer to the byte
2012 Mar 12
0
[LLVMdev] LLI Segfaulting
Hi Fraser,
Is there anything preventing you from using a pointer for the second part of the structure and allocating memory for it later?
Thanks,
Gavin
On Mar 12, 2012, at 10:35 AM, Fraser Cormack wrote:
>
> Hi Duncan,
>
>
> Duncan Sands wrote:
>>
>> Hi Fraser, it looks to me like you are smashing the stack.
>>
>>> define void @main() nounwind {
2012 Mar 12
2
[LLVMdev] LLI Segfaulting
Hi Gavin,
Do you mean something along the lines of having my array struct as { i32,
i32* } and then indexing it with a gep and allocating the appropriate memory
when I learn of it?
Thanks,
Fraser
Gavin Harrison-2 wrote:
>
> Hi Fraser,
>
> Is there anything preventing you from using a pointer for the second part
> of the structure and allocating memory for it later?
>
>
2012 Mar 12
0
[LLVMdev] LLI Segfaulting
Yes, that is what I mean. :-)
On Mar 12, 2012 11:02 AM, "Fraser Cormack" <frasercrmck at gmail.com> wrote:
>
> Hi Gavin,
>
> Do you mean something along the lines of having my array struct as { i32,
> i32* } and then indexing it with a gep and allocating the appropriate
> memory
> when I learn of it?
>
> Thanks,
> Fraser
>
>
> Gavin
2012 Mar 12
1
[LLVMdev] LLI Segfaulting
Sorry for my ignorance, but I'm unaware as to how I'd achieve this.
I know I'd have this,
%MainClass = type { { i32, i32* } }
And something along these lines:
%1 = getelementptr inbounds %MainClass* %0, i32 0, i32 0 ; get to the
'array'
%2 = getelementptr inbounds { i32, i32* }* %1, i32 0, i32 1 ; index the
data pointer
And then I'd want to:
alloca i32, i64 5
2012 Mar 12
0
[LLVMdev] LLI Segfaulting
Hi Fraser, it looks to me like you are smashing the stack.
> define void @main() nounwind {
> allocas:
> %0 = alloca { i32, [0 x i32] }, align 8
^ this allocates 4 bytes on the stack.
> %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1
^ this gets a pointer to the byte after the 4 allocated bytes.
> %3 = bitcast [0 x i32]* %2 to i8*
> call void
2012 Feb 23
1
[LLVMdev] Size of structs & arrays
Eli Friedman-2 wrote:
>
>
> Try llvm::Constant::getNullValue().
>
>
Thanks, that's working nicely (so far).
Eli Friedman-2 wrote:
>
>
> Yes; [0 x i32] isn't really a variable-length array, just a
> placeholder for an array of unknown size. You have to track the size
> yourself.
>
>
This is working, too, however I'm getting a segmentation
2014 Apr 06
2
[LLVMdev] Using StartJnjvmWithJIT from jnjvm.cpp in VMKit
Hi
Does anybody use *StartJnjvmWithJIT* from jvjvm.cpp in VMKit?
Becuase , I am looking to use without JIT when we are running the Java
byte code. My concern is StartJnjvmWithJIT getting three argument *int
argc, char** argv, char* mainClass* - why we need to pass *argv and
mainclass* arguments here?
please help me on this.
Regards
Sri.
-------------- next part --------------
An
2012 Feb 22
0
[LLVMdev] Size of structs & arrays
On Wed, Feb 22, 2012 at 1:56 PM, Fraser Cormack <frasercrmck at gmail.com> wrote:
>
> I'm trying to work out the size of a struct so that I can pass this to the
> 'llvm.memcpy' intrinsic. It's easy to find out how I'm supposed to do this,
> as I keep seeing the following:
>
> %Size = getelementptr %T* null, int 1
> %SizeI = cast %T* %Size to uint
>
2012 Feb 22
5
[LLVMdev] Size of structs & arrays
I'm trying to work out the size of a struct so that I can pass this to the
'llvm.memcpy' intrinsic. It's easy to find out how I'm supposed to do this,
as I keep seeing the following:
%Size = getelementptr %T* null, int 1
%SizeI = cast %T* %Size to uint
But I'm unsure how I actually do this in the C++ API. Is the 'null' here a
llvm::ConstantPointerNull? Any help
2014 Oct 17
2
[LLVMdev] opt -O2 leads to incorrect operation (possibly a bug in the DSE)
Hi all,
Consider the following example:
define void @fn(i8* %buf) #0 {
entry:
%arrayidx = getelementptr i8* %buf, i64 18
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %arrayidx, i8* %buf, i64
18, i32 1, i1 false)
%arrayidx1 = getelementptr i8* %buf, i64 18
store i8 1, i8* %arrayidx1, align 1
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %buf, i8* %arrayidx, i64
18, i32 1, i1 false)
2020 Sep 30
2
lifetime_start/end
Hello,
What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per
my knowledge, they define the live ranges of variables. In the following
code section, they seem redundant. However, when I remove them, the
behavior of the code becomes non-deterministic. The live ranges of the
variables defined by them are never used in the code.
Thanks,
---------------
%37 = bitcast
2017 Mar 31
2
CHECK-LABLE or CHECK?
Hi All,
I came across a FileCheck failure I don't understand why. The
example code below:
void test1() {
... code ...
// CHECK-LABEL: @test1
// CHECK: void @llvm.memcpy.p0i8.p0i8.i32 - (1)
}
void dummy() { // make (1) match
... code ...
// CHECK-LABEL: @dummy
}
void test2() {
... code ...
// CHECK-LABEL: @test2
//
2013 May 21
4
[LLVMdev] malloc / free & memcpy optimisations.
The front end I'm building for an existing interpreted language is
unfortunately producing output similar to this far too often;
define void @foo(i8* nocapture %dest, i8* nocapture %src, i32 %len)
nounwind {
%1 = tail call noalias i8* @malloc(i32 %len) nounwind
tail call void @llvm.memcpy.p0i8.p0i8.i32(i8* %1, i8* %src, i32 %len, i32
1, i1 false)
tail call void
2013 May 21
0
[LLVMdev] malloc / free & memcpy optimisations.
> could you allocate the memory on the stack instead (alloca instruction)?
This is mainly for string or binary blob handling, using the stack isn't a
great idea for size reasons.
While I'm experimenting with simple code examples now, and I picked a
simple one for this email. I'm certain things will get much more
complicated once I implement more features of the language.
On Tue,
2018 Jan 19
0
Change memcpy/memmove/memset to have dest and source alignment attributes
On Jan 18, 2018, at 10:48 PM, Chris Lattner <clattner at nondot.org<mailto:clattner at nondot.org>> wrote:
On Jan 18, 2018, at 7:45 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi all,
This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in:
2018 Mar 22
2
new @llvm.memcpy and @llvm.memset API in trunk - how to use alignment?
The new @llvm.memcpy API does not have an alignment parameter. Instead the
docs say to use the align <n> attribute. How is this supposed to work with
different alignments?
For example, I have one memcpy with align 4, align 4, and another with
align 1, align 1.
; Function Attrs: argmemonly nounwind
declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly align 4,
i8* nocapture
2018 Nov 23
2
is this a bug in an optimization pass?
The frontend code is a pretty simple for loop, that counts from i = 0;
i != 10; i += 1
It gets optimized into and endless loop.
export fn entry() void {
var array: [10]Bar = undefined;
var x = for (array) |elem, i| {
if (i == 1) break elem;
} else bar2();
}
Here's the generated IR:
; ModuleID = 'test'
source_filename = "test"
target datalayout =
2018 Mar 22
0
new @llvm.memcpy and @llvm.memset API in trunk - how to use alignment?
On 3/22/2018 3:15 PM, Andrew Kelley via llvm-dev wrote:
> The new @llvm.memcpy API does not have an alignment parameter. Instead
> the docs say to use the align <n> attribute. How is this supposed to
> work with different alignments?
>
> For example, I have one memcpy with align 4, align 4, and another with
> align 1, align 1.
>
> ; Function Attrs: argmemonly
2017 May 16
4
Which pass should be propagating memory copies
Consider the following IR example:
define void @simple([4 x double] *%ptr, i64 %idx) {
%stack = alloca [4 x double]
%ptri8 = bitcast [4 x double] *%ptr to i8*
%stacki8 = bitcast [4 x double] *%stack to i8*
call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32,
i32 0, i1 0)
%dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32
0, i64 %idx