search for: isbitcastable

...(i32*)* @g to i32 (i64)*)(i64 %a) ret i32 %call } > > The idea of improving the inliner is also great, but you may find that > it's needed for cases other than this one if i'm right about the > instcombine. > Sadly, the combine fails because InstCombine queries CastInst::isBitCastable to determine the castable-ness of the parameter type and the argument type. It isn't bitcastable though, it's ptrtoint/inttoptr castable. The following patch opens up the optimization: --- a/lib/Transforms/InstCombine/InstCombineCalls.cpp +++ b/lib/Transforms/InstCombine/InstCombineCalls....

Philip, I post here because I think AlwaysInliner should inline it. I want to detect the indirect calls for Inliner, and I want to hear inputs. let me define indirect call first in my idea. In one single expression, one function may be subject to bitcast more than one time. we can detect this situation and treat it as a regular call of last function, is that okay? thanks, --lx On Mon, Jan 5,

Alp noted that the current setup on how phab reviews land on the list are not working for him. I'd be curious whether his setup is special, or whether there are more widespread problems. If this is more widely perceived as a problem, please speak up, and I'll make sure to prioritize the fixes (note that this is unrelated to the "lost email" problem - those are always highest

...rns true and make use of the size when calculating offsets. We have considered introducing multiple helper functions instead of using direct size queries, but that doesn't cover all cases. It may still be a good idea to introduce them to make the purpose in a given case more obvious, e.g. 'isBitCastableTo(Type*,Type*)'. ======================================== 3. Representing Vector Length at Runtime ======================================== With a scalable vector type defined, we now need a way to represent the runtime length in IR in order to generate addresses for consecutive vectors in me...