On Thu, Jan 19, 2017 at 6:46 PM, Pekka Jääskeläinen <pe...@parmance.com> wrote: > Hi Jakub and Richard, > > Attached is an updated BRIG FE patch which adds the HSAIL related > builtins only internally in the BRIG FE. I didn't add LTO support as I > believe it's not > useful for BRIG FE due to it always inputting fully linked BRIGs and > not mixing with > other frontends.
So the #ifdef ENABLE_BRIG_FE shouldn't be needed anymore (nor the configury for it). Otherwise this looks ok to me then. Thanks, Richard. > BR, > Pekka > > > > On Mon, Jan 16, 2017 at 11:07 AM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Mon, Jan 16, 2017 at 09:46:43AM +0100, Richard Biener wrote: >>> 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 ;) >> >> I guess the question is when the DEF_HSAIL* builtins are actually needed. >> If the FE is separate from the other FEs, I guess it would be enough to >> define those builtins >> 1) in the BRIG FE >> 2) in tree-core.h >> 3) in lto1 (only if any such builtin has been seen in the IL >> >> So, perhaps define DEF_HSAIL* just to DEF_BUILTIN_STUB in builtins.def >> unless already defined, and override it in the BRIG FE where you create its >> builtins, and then have some routine in the middle-end similar to >> initialize_sanitizer_builtins which lazily initializes the DEF_HSAIL* >> builtins during LTO reading if a call to any of the builtins in the hsail >> range is noticed? >> >> Jakub
