On Fri, Jan 13, 2017 at 4:54 PM, Pekka Jääskeläinen <pe...@parmance.com> wrote: > On Fri, Jan 13, 2017 at 2:34 PM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Thu, Jan 12, 2017 at 3:55 PM, Pekka Jääskeläinen <pe...@parmance.com> >> wrote: >>> Hi, >>> >>> A gentle ping... >> >> Looking at 002/ >> >> What's the reason of having brig-builtins.def? I do not see any >> middle-end stuff using them >> and if you just emit calls to the runtime then you do not need >> "builtins" for this -- just build >> the function decls in the frontend. The Fortran frontend has examples >> for how to do that >> for almost all entries to the libgfortran runtime. >> >> So all changes besides in brig/ look unnecessary to me. > > Most of the HSAIL instructions represented as builtins here are fine > grained enough for > them to be candidates for expanding as sensible target instruction > sequences instead of runtime > function calls. > > I understand that there is no code in any of the targets to do so yet. > But still I wonder is it > meaningful to convert them to direct runtime function calls -- if/when > a target wants > to optimize their HSAIL codegen they have to be moved back. Especially given > the BRIG FE is not enabled by default and the inclusion of the BRIG > builtins is done > only if enabled, does it cause harm?
There are 187 of them (well, simple grep of DEF_HSAIL, so probably a bit less). They aren't really documented but I guess that __hsail_bitmask_u64 for example is really equivalent to sth like -1U >> n << m? So I'm not sure why you have builtins like these represened as functions rather than as "expanded" code sequences? If that's the ones you are talking about having special target specific expansion. Note that builtins add to GCC startup times and if you don't expect people to enable BRIG then I wonder why you are submitting it for inclusion ;) Richard. > BR, > --Pekka
