Displaying 5 results from an estimated 5 matches for "ailgnment".
2009 Jan 12
2
[LLVMdev] malloc vs malloc
...tionally take 64-bit sizes.
>>
>> I'm curious. Do we want to keep the free instruction?
>
> No, there's no reason to.
There still are reasons to have it; just grep around for FreeInst.
Function
attributes are not yet sufficient to replace all of those yet.
And if the ailgnment attribute on MallocInst were implemented, perhaps
via posix_memalign or other target-specific mechanisms, then MallocInst
would also have a reason to be kept.
Dan
2009 Jan 12
0
[LLVMdev] malloc vs malloc
...>> I'm curious. Do we want to keep the free instruction?
>>
>> No, there's no reason to.
>
>
> There still are reasons to have it; just grep around for FreeInst.
> Function
> attributes are not yet sufficient to replace all of those yet.
>
> And if the ailgnment attribute on MallocInst were implemented, perhaps
> via posix_memalign or other target-specific mechanisms, then
> MallocInst
> would also have a reason to be kept.
isa<FreeInst>(X) can be replaced with:
bool isFree(Instruction *X) {
if (CallInst *CI = dyn_cast<CallInst>...
2009 Jan 11
2
[LLVMdev] malloc vs malloc
Chris Lattner wrote:
> On Dec 23, 2008, at 9:14 AM, Jon Harrop wrote:
>> I discovered that LLVM's malloc only allows a 32-bit size argument,
>> so you
>> cannot use it to allocate huge blocks on 64-bit machines. So I
>> considered
>> replacing all of my uses of LLVM's malloc instruction with calls to
>> the libc
>> malloc function instead.
2009 Jan 11
0
[LLVMdev] malloc vs malloc
>> There is no good reason for malloc to be an instruction anymore. I'd
>> be very happy if it got removed. Even if we keep it, malloc/alloca
>> should be extended to optionally take 64-bit sizes.
>
> I'm curious. Do we want to keep the free instruction?
No, there's no reason to.
-Chris
2009 Jan 13
2
[LLVMdev] malloc vs malloc
...;m curious. Do we want to keep the free instruction?
>>> No, there's no reason to.
>>
>> There still are reasons to have it; just grep around for FreeInst.
>> Function
>> attributes are not yet sufficient to replace all of those yet.
>>
>> And if the ailgnment attribute on MallocInst were implemented, perhaps
>> via posix_memalign or other target-specific mechanisms, then
>> MallocInst
>> would also have a reason to be kept.
>
> isa<FreeInst>(X) can be replaced with:
>
> bool isFree(Instruction *X) {
> if (Ca...