RE: builtin function - novops

[Bingfeng Mei <bmei at broadcom 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.

Bingfeng

-----Original Message-----
From: Richard Biener [mailto:richard.guenther@gmail.com] 
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
<hariharan.gcc@gmail.com> wrote:
> Hello,
> This question is similar to one raised by bingfeng here
>
> http://gcc.gnu.org/ml/gcc/2010-04/msg00241.html
>
> 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[0], s->x[1]);
> __builtin_mac (s->x[0] + 5, s->x[1] + 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"
output

- model the builtins not as builtins but as inline asm which can have
multiple outputs

Richard.

> Thanks and regards
> Hari