Basically this patch looks fine to me. You can check it in at first then try to optimize it later.
2010/12/8 shuxin yang <shuxin.ope...@gmail.com> > This intrinsic is slightly different from others in that it needs some data > flow analysis to tell the constant it folded to. In the long run, I think > the BE try to fold it whenever possible. Apparently, > CG is too late. If you check the definition of the intrinsic definition, I > flagged it as non-CG intrinsic. > > I did't hard-code to prevent future change. If one want to pass it down to > BE, simply remove the > the Fold_object_size(). > > Also note that this intrinsic is marked as side-effect-free intrinsic op, > it can be optimized in the backend like an arithmetic expression. > > Shuxin > > > On Wed, Dec 8, 2010 at 12:18 PM, Jian-Xin Lai <laij...@gmail.com> wrote: > >> I wonder it's better to pass this intrinsic to BE and lower it just before >> CGEXP phase. So that we keep the opportunity to optimize it in wopt in the >> future. >> >> Another suggestion, for the ID of the intrin, "INTRN_OBJECT_SIZE" is >> better than "INTRN_OBJ_SZ". >> >> 2010/12/8 shuxin yang <shuxin.ope...@gmail.com> >> >>> Hi, there: >>> >>> Bug 586 is about back-end folding gcc extension >>> __builtin_object_size() into a compile time constant. >>> >>> If I understand right, "__builtin_object_size(void*p, int type)" >>> depends on compiler's capability >>> of data flow analysis; if the compiler is able to reveal the object O >>> that <p> points to, it will returns >>> sizeof(typeof(O)); otherwise, it returns "type < 2? -1 : 0". >>> >>> gcc tries to fold this built-in function in many places; it calls >>> fold_builtin_object_size()@builtin.c >>> prior to generic -> gspin conversion. However, fold_builtin_object_size() >>> is only able to handle simple cases; >>> general cases are taken cared by a pass named "objsz" (see >>> tree-object-size.c) which rely on >>> SSA and it is called after the generic->gspin conversion. >>> >>> My fix, honestly kludge, is simply to replace the builtin function >>> with "type < 2 ? -1 : 0". >>> In the long run, the back-end should have full-blown support. >>> >>> Thanks >>> Shuxin >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF Dev2Dev email is sponsored by: >>> >>> WikiLeaks The End of the Free Internet >>> http://p.sf.net/sfu/therealnews-com >>> _______________________________________________ >>> Open64-devel mailing list >>> Open64-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >>> >> >> >> -- >> Regards, >> Lai Jian-Xin >> > > -- Regards, Lai Jian-Xin
------------------------------------------------------------------------------
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
