MSVC hook function prologue

[Paolo Bonzini]

> Currently I still have these problems:
> *) There is apparently some plugin framework in the works. Can this
> functionality implemented as a plugin?

No, plugins do not affect the backend.

> *) The stack alignment code + msvc_prologue is used by Wine on osx though.
> Currently I pop %ebp after the 5 byte prologue, and the normal code recreates
> the frame pointer afterwards. My understanding is that I can avoid this by
> keeping the original frame pointer, but adjusting a lot of offsets after the
> alignment to find the function parameters and align the stack properly on
> calls. However, this is currently above my head.

I don't think this would prevent the patch from getting the patch in.

> *) What other changes are needed to get a functionality like this into
> mainline?

I think right now I'd make only two cosmetic adjustments:

Here:

    if (!TARGET_64BIT)
      {
-      warning (OPT_Wattributes, "%qE attribute only available for 64-bit",
-	       name);
-      *no_add_attrs = true;
-      return NULL_TREE;
+      if(!is_attribute_p ("msvc_prologue", name))

I'd say

    if (TARGET_64BIT
        ? !is_attribute_p ("msvc_prologue", name))
        : is_attribute_p ("msvc_prologue", name))
      {
        warning (OPT_Wattributes, "%qE attribute not available for "
                 "%d-bit", name, TARGET_64BIT ? 64 : 32);
        *no_add_attrs = true;
        return NULL_TREE;
     }

And here:

+(define_insn "vswapmov"
+[(unspec_volatile [(match_operand 0 "register_operand" "0")
+                   (match_operand 1 "register_operand" "1")]
+ UNSPECV_VSWAPMOV )]

I'd try defining the insn as

(define_insn "vswapmov"
[(set (match_operand 0 "register_operand" "0")
       (match_operand 1 "register_operand" "1")
  (unspec_volatile [] UNSPECV_VSWAPMOV)]

I think this should work and would be nicer to the compiler's dataflow 
analysis, but it should be tested of course.

I'm not an x86 maintainer, though.

Paolo