This is the mail archive of the
mailing list for the GCC project.
Re: builtin function - novops
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Hariharan Sandanagobalane <hariharan dot gcc at gmail dot com>
- Cc: Bingfeng Mei <bmei at broadcom dot com>, Andrew Haley <aph at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 17 Mar 2014 10:11:48 +0100
- Subject: Re: builtin function - novops
- Authentication-results: sourceware.org; auth=none
- References: <CANq-hQiy_6otat5msHGU83=AeeEoLeVo62Z3AEokykveysCwVw at mail dot gmail dot com>
On Mon, Mar 17, 2014 at 1:59 AM, Hariharan Sandanagobalane
> This question is similar to one raised by bingfeng here
> In our private port based on GCC 4.8.1, i want to define a builtin function
> for multiply and accumulate. The function uses the input parameters and
> modifies the accumulator. The accumulator can be read using special builtin
> functions. If i had
> __builtin_mac (s->x, s->x);
> __builtin_mac (s->x + 5, s->x + 5);
> I want s->x[0,1] to be loaded once and used for both invocations.
> I can not use either pure or constant since that will eliminate these
> functions. I tried using novops within builtin declaration in the port, but
> that doesn't seem to do the trick either. What attribute should i be using
> in this scenario?
There isn't (and there can't be) a magic attribute that will make the compiler
know that implicit dependency between those builtins.
The only "implicit" dependency we have is "global memory" which
means "no attribute" is the correct attribute to use.
The other variant is to make the dependency explicit - which is hard
as mac already has an output and a call can at most have one.
There are several possible work-arounds
- add a 2nd output via a address argument &SPECIAL_DECL and add a "fn
spec" attribute to the builtin that tells the alias machinery about
the fns behavior (doesn't work - "fn spec" can't make the function
otherwise const, something we'd need to fix)
- do the above but special-case the builtins in the alias
disambiguators to only consider memory dependences on that 2nd "fake"
- model the builtins not as builtins but as inline asm which can have
> Thanks and regards