> I see. I guess dropping them if !virtual_method_call_p (at what point > do we know?) would be a good thing. As well as encoding > "types_same_for_odr" and obj_type_ref_class in a more direct manner. > I guess in reality OBJ_TYPE_REF should be all info on the > gimple_call rather than in a GENERIC tree in the call fn slot or > a separate stmt ... > > Anyhow, the original patch is OK if you compare > OBJ_TYPE_REF_TOKEN/OBJECT irrespective of virtual_method_call_p > and order the types_same_for_odr last since that's most expensive. > I also wonder if virtual_method_call_p needs to return a virtual_mehtod_call_p is constant on the expression thorough compilation. I.e. if OBJ_TYPE_REF is born in C++ FE it will return true if it is Obj-C FE it will return false and we will completely ignore that OBJ_TYPE_REF in the middle-end (and thus we probably want to drop it - I was just never brave enough to dig into obj-C gimplification to figure out where it should be done and I also do not know how OBJ-C uses OBJ_TYPE_REFs internally if at all)
Honza > "maybe" and we have to say not equal in that case rather than just > not comparing obj_type_ref_class ... (operand_equal_p might be called > from FEs during parsing) > > Richard. > > Thanks, > Richard. > > > Honza