This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] BRIG frontend: request for a global review


OK,

I'll see into adapting the Jakub's idea and also check if some of the
simplest builtins are better expanded
directly to tree nodes instead.

I'm not sure if lto support is needed though as the assumption now is
to have fully linked input to this FE
(all necessary BRIG modules fed in at build time which can be
guaranteed by the HSA finalizer runtime API)
without modules from other FEs never linked in.

Quickly testing, I couldn't measure startup time difference with the
builtins on/off, but of course there
will be some cycles wasted somewhere especially if some code in gcc
traverses all the builtins.

For the audience that might want to enable the FE, I expect the BRIG
FE to be used with x86_64
to have an HSA CPU Agent e.g. with phsa to avoid the need for a HSA
supported GPU in the
machine for developing HSA using projects, and also by other HSA
finalizer implementations
downstream or up. Hopefully this includes also finalization for
AMDGPUs or PTX in the future (if someone
is interested in implementing it). So, there might not be "mainstream
needs" currently that would
warrant enabling by default currently for masses, but hopefully more
so in the future after HSA gets
wider adoption.

Thanks,
Pekka

On Mon, Jan 16, 2017 at 11:07 AM, Jakub Jelinek <jakub@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]