Displaying 7 results from an estimated 7 matches for "allocmemory".
Did you mean:
all_memory
2016 Jan 04
3
Can someone give me some pointer on alias analysis ?
...That's definitely not recommended since it will
> greatly limit your choices when encountering an issue like this.
>
>
I just reused an old code sample. The problem still exists in recent
version of LLVM.
> Second, the aliasing problem has to do with the effects of the
> "allocmemory" callsite on a memory location associated with an earlier
> alloca. There's nothing that prevents your allocmemory function from
> writing to global state. You have to teach the alias analysis that an
> unescaped noalias pointer can't alias the global state allocmemory might...
2015 Dec 26
2
Can someone give me some pointer on alias analysis ?
I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049
It turns out this is the kind of optimization that I really need, as when
it isn't done, all kind of other optimizations opportunities down the road
are not realized as they are not exposed.
I have no idea where to start digging for this. I assume there is some kind
of interaction between memory dependency and alias
2015 Aug 20
3
[RFC] Aggreate load/store, proposed plan
...form, so we should transform the IR, when possible, into our preferred canonical form.
-Hal
> turns aggregate
> load/store into a load/store using an integer of equivalent size and
> insert the correct bitcast before/after, right?
>
> Example is:
>
> %0 = tail call i8* @allocmemory(i64 32)
> %1 = bitcast i8* %0 to %B*
> store %B { %B__vtbl* @B__vtblZ, i32 42 }, %B* %1, align 8
>
> into:
>
> store i128 or (i128 zext (i64 ptrtoint (%B__vtbl* @B__vtblZ to i64)
> to i128), i128 774763251095801167872), i128* %1, align 8
>
> Where the aggregate is:...
2016 Jan 04
3
Can someone give me some pointer on alias analysis ?
...it will greatly limit your choices when
> encountering an issue like this.
>
>
> I just reused an old code sample. The problem still exists in
> recent version of LLVM.
>
> Second, the aliasing problem has to do with the effects of the
> "allocmemory" callsite on a memory location associated with an
> earlier alloca. There's nothing that prevents your
> allocmemory function from writing to global state. You have
> to teach the alias analysis that an unescaped noalias pointer
> can't ali...
2015 Aug 20
2
[RFC] Aggreate load/store, proposed plan
...the scalar
> after loading and the aggregate to a scalar when storing.
>
>
> For instance, the following IR (extracted from a D frontend) :
>
> %B__vtbl = type { i8*, i32 (%B*)* }
> @B__vtblZ = constant %B__vtbl { i8* null, i32 (%B*)* @B.foo }
>
> %0 = tail call i8* @allocmemory(i64 32)
>
> %1 = bitcast i8* %0 to %B*
> store %B { %B__vtbl* @B__vtblZ, i32 42 }, %B* %1, align 8
>
>
> Would be canonized into :
> %0 = tail call i8* @allocmemory(i64 32)
> %1 = bitcast i8* %0 to i128*
> store i128 or (i128 zext (i64 ptrtoint (%B__vtbl* @B__vtblZ to...
2015 Aug 21
3
[RFC] Aggreate load/store, proposed plan
...ggregate to a scalar when storing.
> >
> >
> > For instance, the following IR (extracted from a D frontend) :
> >
> > %B__vtbl = type { i8*, i32 (%B*)* }
> > @B__vtblZ = constant %B__vtbl { i8* null, i32 (%B*)* @B.foo }
> >
> > %0 = tail call i8* @allocmemory(i64 32)
> >
> > %1 = bitcast i8* %0 to %B*
> > store %B { %B__vtbl* @B__vtblZ, i32 42 }, %B* %1, align 8
> >
> >
> > Would be canonized into :
> > %0 = tail call i8* @allocmemory(i64 32)
> > %1 = bitcast i8* %0 to i128*
> > store i128 or (i12...
2015 Aug 20
2
[RFC] Aggreate load/store, proposed plan
It is pretty clear people need this. Let's get this moving.
I'll try to sum up the point that have been made and I'll try to address
them carefully.
1/ There is no good solution for large aggregates.
That is true. However, I don't think this is a reason to not address
smaller aggregates, as they appear to be needed. Realistically, the
proportion of aggregates that are very large