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.
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
002-brig-fe-gcc.patch.gz
Description: GNU Zip compressed data
005-diff-to-previous.patch.gz
Description: GNU Zip compressed data
