[LLVMdev] Verifier should not make any assumptions about calls to "malloc"

[Duncan Sands]

Hi Victor,

> What does the Ada front-end declare malloc as?

I don't really want to tell you because a correct solution should work
no matter what malloc is defined to be :)  What I mean by "work" is that
if malloc has the standard prototype then you perform transforms on it,
and otherwise you should probably just ignore it.

That said, Ada outputs 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 use the declared return type of 
> malloc.  I need to understand more about how this is breaking Ada to 
> determine how to resolve this.  Removing this check from the verifier 
> could end up being the resolution.

I think you should just not even try to do transforms on a function that
happens to be called "malloc" if it doesn't have the conventional
prototype.  I reckon isMalloc should just return false for something
called "malloc" but that doesn't return i8* or has too many parameters
etc.

>> 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
>> SimplifyLibcalls?
> 
> The free-standing environment with a non-memory-allocating malloc 
> function will be handled via -fno-builtins.  I don't believe that 
> isMalloc is bogus, just that llvm does not support the ability to turn 
> it off.

Yes, isMalloc is not the only sinner here - fixing this would be a
whole new project.

Ciao,

Duncan.