This is the mail archive of the
mailing list for the GCC project.
RE: builtin function - novops
- From: Bingfeng Mei <bmei at broadcom dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Hariharan Sandanagobalane <hariharan dot gcc at gmail dot com>
- Cc: Andrew Haley <aph at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 17 Mar 2014 09:58:49 +0000
- Subject: RE: builtin function - novops
- Authentication-results: sourceware.org; auth=none
- References: <CANq-hQiy_6otat5msHGU83=AeeEoLeVo62Z3AEokykveysCwVw at mail dot gmail dot com> <CAFiYyc0Pf6Pjspbspp4tWS8VRMUtW0p0Whu=M_YD-YE2XqCu9A at mail dot gmail dot com>
In our case, we make MAC register explicit by defining a new
type of register (data type). To use your mac instruction, you must have
a first instruction to only write to the mac register. In the
following mac builtins, the mac register can be both input/output
and therefore dependency is respected and your builtins won't
be optimized away. This is useful especially if you have multiple
mac registers and requires gcc to do register allocation.
From: Richard Biener [mailto:firstname.lastname@example.org]
Sent: 17 March 2014 09:12
To: Hariharan Sandanagobalane
Cc: Bingfeng Mei; Andrew Haley; GCC Development
Subject: Re: builtin function - novops
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