Re: Preventing scheduling of normal operations across calls to built-ins

[Ayonam Ray <ayonam at gmail dot com>]

On 22 February 2012 07:24, Ian Lance Taylor <iant@google.com> wrote:
> Ayonam Ray <ayonam@gmail.com> writes:
>
>> What I can't understand is that why is the RTL reordered right at the
>> expand stage itself. ?If I turn off the optimization, then the reorder
>> at the expand stage doesn't happen. ?This can be seen in the expand
>> output at -O0. ?I am wondering if there is some issue with the manner
>> in which the built-ins are initialized which makes the compiler think
>> that they do not affect program state.
>
> It looks like the function calls are being rearranged before you ever
> get to the RTL. ?What does your original source code look like? ?How
> precisely are you defining the builtin functions?
>
> Ian

The original source code is like below:

int simpleAddition(int *res, int intVal, int oneVal, int oneVal1)
{
  int val;
  int val1;
  *res = 0;

  __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;

  if (~val)
    *res = 1;
  else
    *res = 0;

  return *res;
}

The built-ins are defined as follows:

tree endLink              = void_list_node;
tree intEndLink          = tree_cons(NULL_TREE, integer_type_node, endLink);
tree intIntEndLink      = tree_cons(NULL_TREE, integer_type_node, intEndLink);
tree intFtypeInt          = build_function_type(integer_type_node, intEndLink);
tree voidFtypeIntInt   = build_function_type(void_type_node, intIntEndLink);

add_builtin_function("__builtin_mvc_from_ccr", intFtypeInt,
                       BUILTIN_MVC_FROM_CCR, BUILT_IN_MD, NULL,
                       NULL_TREE);

add_builtin_function("__builtin_mvc_to_ccr", voidFtypeIntInt,
                       BUILTIN_MVC_TO_CCR, BUILT_IN_MD, NULL, NULL_TREE);

Thereafter, I do an expansion wherein I check for the correctness of
the operands by calling the relevant predicates of the RTL with the
corresponding operands and then moving operands to registers if
needed.  Then I generate the RTL using the final operands.

Now here, there is something that I suspect to be the cause.  The
arguments to the builtin for mvc_to_ccr are both immediate values.
The first one comes in as an enum specifying the CCR register number
which gets converted to a CCR register from the register file and the
second one is an immediate value that gets moved to a register in the
expansion stage.

I'm wondering whether the compiler upon seeing an enum and an
immediate value as the arguments to the builtin is assuming that the
builtin does not have or create any dependence on the rest of the
code.

Thanks and regards
Ayonam