This is an archive of the discontinued LLVM Phabricator instance.

[GlobalOpt] [MemoryBuiltins] Update getMallocType with bitcast on stored pointer
AbandonedPublic

Authored by scui on Aug 5 2021, 8:16 AM.

Details

Summary

Currently, getMallocType checks the bitcast uses of the malloc call. If there is no bitcast uses of the malloc call, malloc function’s return type is returned. Sometimes, the bitcast is on the stored-to pointer instead of on the malloc call. This patch is to also consider the cases like this:

%call = call i8* @malloc
store i8* %call, i8** bitcast (%T** @g to i8**)

Diff Detail

Unit TestsFailed

Event Timeline

scui created this revision.Aug 5 2021, 8:16 AM
scui requested review of this revision.Aug 5 2021, 8:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 5 2021, 8:16 AM

If you going to mess with this code, can you just kill off all the malloc use type heuristics, and just unconditionally create an [i8 x n] array? The existing type sniffing code won't work with opaque pointers anyway.

scui added a comment.Aug 5 2021, 3:07 PM

If you going to mess with this code, can you just kill off all the malloc use type heuristics, and just unconditionally create an [i8 x n] array? The existing type sniffing code won't work with opaque pointers anyway.

The existing code has been there for a while. It tries to get the type for the code in the following pattern:

%call = call i8* @malloc
 %0 = bitcast i8* to T*
 store T* %0, %T** @g

This somehow can be transformed to the code:

%call = call i8* @malloc
store i8* %call, i8** bitcast (%T** @g to i8**)

The code here is trying to recognize the code pattern.

It looks to me the IR code will be sub-optimal for some cases if we simply return Type i8* for getMallocType. I’m thinking maybe we can return just either the only bitcasted type or the malloc return type, ie, no nullptr return, but I’m not sure if this really matters for real cases.

It looks to me the IR code will be sub-optimal for some cases if we simply return Type i8* for getMallocType.

Will it? Almost all optimizations can deal with bitcasts of global variables without getting confused.

Anyway, if you want to refine the type of the global created by the transform, I guess that's okay, but confusion about the types involved shouldn't ever block the transform.

scui added a comment.Aug 6 2021, 8:29 AM

It looks to me the IR code will be sub-optimal for some cases if we simply return Type i8* for getMallocType.

Will it? Almost all optimizations can deal with bitcasts of global variables without getting confused.

I could be wrong. One case I can imagine is to set initial value, for example, an i32 value for [4 x i8] global.

Anyway, if you want to refine the type of the global created by the transform, I guess that's okay, but confusion about the types involved shouldn't ever block the transform.

I'm also confused with the nullptr return with the existing code. I'll try another version to limit to looking into only the store from the malloc call, and see if that will make more sense.

scui updated this revision to Diff 364837.Aug 6 2021, 10:02 AM

Rewrite getMallocType - only look at the bitcast feeding into the store (value or pointer) for malloc call, and no longer return nullptr.

At this point, the code is really specific to GlobalOpt transform; maybe we want to move it into GlobalOpt.cpp?

llvm/lib/Analysis/MemoryBuiltins.cpp
354

Update here as well?

366

We still end up blocking the transform in some cases: if the malloc size isn't a multiple of the type inferred by getMallocType(), the transform fails.

nikic added a subscriber: nikic.Aug 10 2021, 2:10 PM

Would it be possible to drop getMallocType, only keep getMallocAllocatedType, and determine the type based on the value type of a (possibly bitcasted) store to the address? That would be forward compatible with opaque pointers.

D117092 implements @efriedma's suggestion of always using an [i8 x Size] type.

ormris removed a subscriber: ormris.Jan 18 2022, 9:51 AM
reames requested changes to this revision.Feb 3 2022, 9:04 AM
reames added a subscriber: reames.

Appears to have been subsumed by other changes. Please close or rebase if there's still something missing.

This revision now requires changes to proceed.Feb 3 2022, 9:04 AM
scui abandoned this revision.Feb 3 2022, 9:15 AM