This is the mail archive of the gcc-help@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]

Preventing scheduling of normal operations across calls to built-ins


I have a set of built-ins implemented using unspec_volatile which set
various processor control modes for rounding, overflow, etc.
Now what I see is that if I call these builtins in between the
arithmetic operations in C code, at -O1 and -O2, it puts together all
those calls to the built-ins at the top of the function body and sends
all the arithmetic operations below.  Effectively, the arithmetic
operations do not conform to the processor modes that I am setting.
The same code works fine at -O0, i.e., the operations are not
reordered (as expected).

An example of such a test case is shown below:

<quot>
  __builtin_mvc_to_ccr(0x0, CCR8);      // Configuration for
wrap_aroung logic...

  val = (intVal - oneVal);
  val += oneVal1;


  __builtin_mvc_to_ccr(0xffffffff, CCR8);   // Configuration for
saturation_logic..
  val1 = __builtin_mvc_from_ccr(CCR8);
  val += val1;


  __builtin_mvc_to_ccr(0x0, CCR8);      // Configuration for
wrap_aroung logic...
  val1 = intVal;

  val += val1;

<unquot>

Here all the calls to the built-ins happen first and then the
arithmetic operations.  The built-in __builtin_mvc_to_ccr() is a void
function.

Where am I going wrong in my implementation?  I have tried inserting
calls to gen_blockage() and emit_barrier() around the place where I
expand these built-ins.  With gen_blockage() there is no effect and
with the emit_barrier() the code generation stops beyond the point
where the barrier is emitted.

Thanks in advance.
Regards
Ayonam


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