Add support for allockind without allocsize

[nunoplopes]

This produces an invalid expr:

define i64 @src() {
  %stack = call ptr @myalloc()
  %sz = call i64 @llvm.objectsize.i64.p0(ptr %stack, i1 false, i1 false, i1 false)
  ret i64 %sz
}

define i64 @tgt() {
  ret i64 -1
}

declare ptr @myalloc() allockind("alloc")
declare i64 @llvm.objectsize.i64.p0(ptr, i1, i1, i1)

[IamYJLee]

Thank you for the feedback. (#1239)
When allocsize is missing in the myalloc function, should it return null or allocate a fresh block if it’s non-null? Since allockind("alloc") implies returning either null or a new block, I’d appreciate your advice on the resolution.

[nunoplopes]

It's already allocating a new block. It's just it's setting the size as null instead of creating a fresh var in src, and reusing the same var in tgt. It requires some changes in state.cpp & memory.cpp.

[IamYJLee]

Thanks for the advice.
I’ve started working on this.

[IamYJLee]

@nunoplopes

Thank you very much for your continuous support. I would like to ask for your guidance on the following:

In this situation, should the handling differ from the case where an allocsize attribute is present — for example, by using addFnCall — or should it still be processed through m.alloc in the same way?

In either case — whether following the addFnCall logic or the allocsize logic — could you please advise on the appropriate way to handle situations where allocsize is not specified? I have a reasonable understanding of the behavior when allocsize is available, but I am uncertain about the proper approach when it is absent.

[nunoplopes]

Yes, it should go through alloc(), as that's the function that can create new local blocks. The issue is that the size needs to be set to a non-deterministic value. And this value must be equal in both src & tgt. This needs to go into FnCallOutput (state.h)