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.guent...@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....@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