search for: ismalloc

...if I have my own runtime in which "malloc" is completely different to the usual one? From my reading of the gcc docs, malloc is not provided in a freestanding environment and thus cannot be assumed to be the normal malloc. I think this code should be removed from the verifier. Instead, isMalloc should also check the number of parameters and their types, as well as the return value. Actually isMalloc also seems bogus. In a freestanding environment there is no reason that a function that happens to be called "malloc" should have anything to do with memory allocation. Do you hav...

...malloc as: i32 @malloc(i32) I'm perfectly happy for this not to be optimized - if the Ada frontend wants malloc to be optimized I think it is reasonable to require it to define malloc in a more conventional way. >> I think this code should be removed from the verifier. Instead, >> isMalloc should also check the number of parameters and their types, >> as well as the return value. > > The verifier code is needed because when a malloc return value is used > directly, not via a bitcast, the type of the malloc is determined to be > i8*. But that could be updated to...

...o the > usual one? From my reading of the gcc docs, malloc is not provided > in a freestanding environment and thus cannot be assumed to be the > normal malloc. What does the Ada front-end declare malloc as? > > I think this code should be removed from the verifier. Instead, > isMalloc should also check the number of parameters and their types, > as well as the return value. The verifier code is needed because when a malloc return value is used directly, not via a bitcast, the type of the malloc is determined to be i8*. But that could be updated to use the declared retur...

...n I recode the behavior one > can expect from the AllocationInst? Should I check for call > instructions to malloc? AllocationInst was a superclass of the AllocaInst and MallocInst, the latter of which was deleted so AllocationInst was removed. In LLVM, a lot of code was updated to use the isMalloc() out of include/llvm/Analysis/MemoryBuiltins.h, but "isa<AllocaInst>(...) || isMalloc(...)" would be closest to "isa<AllocationInst>(...)". Nick > I'm new to llvm and I would really appreciate any comment or suggestion. > > Thanks, > Hamid > _...

Hi all, I am working on some old code which was compiled against llvm-2.5. Anyway, in some places I, AllocationInst is used (e.g. to ensure the instruction's type). Even in your current documentation (http://llvm.org/docs/ProgrammersManual.html), I found an example that uses this instruction. If I got it correctly, this istruction (AllocationInst) has been removed from llvm instruction set.

...> const PointerType *PTy = > > PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext())); > Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI); > } Yes, I agree, the verifier shouldn't worry about malloc calls. > Actually isMalloc also seems bogus. In a freestanding environment > there is no reason that a function that happens to be called "malloc" > should have anything to do with memory allocation. Do you have a > plan to handle this? Shouldn't all malloc manipulations be done from > SimplifyLi...

I've just noticed this, in Instruction::isSafeToSpeculativelyExecute(): http://llvm.org/doxygen/Instruction_8cpp-source.html#l00408 00430 case Load: { 00431 if (cast<LoadInst>(this)->isVolatile()) 00432 return false; 00433 if (isa<AllocaInst>(getOperand(0)) || isMalloc(getOperand(0))) 00434 return true; This says that it's safe to speculatively execute a load from the pointer returned by malloc(). But surely that's not true if malloc() returns NULL. Thanks, Jay.

...ne >> can expect from the AllocationInst? Should I check for call >> instructions to malloc? > AllocationInst was a superclass of the AllocaInst and MallocInst, the > latter of which was deleted so AllocationInst was removed. > > In LLVM, a lot of code was updated to use the isMalloc() out of > include/llvm/Analysis/MemoryBuiltins.h, but "isa<AllocaInst>(...) || > isMalloc(...)" would be closest to "isa<AllocationInst>(...)". As a related aside, I've been thinking for awhile that it would be nice to have an allocator analysis group....

...ading of the gcc docs, malloc is not provided >> in a freestanding environment and thus cannot be assumed to be the >> normal malloc. > > What does the Ada front-end declare malloc as? > >> >> I think this code should be removed from the verifier. Instead, >> isMalloc should also check the number of parameters and their types, >> as well as the return value. > > The verifier code is needed because when a malloc return value is used > directly, not via a bitcast, the type of the malloc is determined to > be i8*. But that could be updated to use...