This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MSVC hook function prologue
- From: Paolo Bonzini <bonzini at gnu dot org>
- To: Stefan Dösinger <stefan at codeweavers dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 03 Sep 2009 00:04:43 +0200
- Subject: Re: MSVC hook function prologue
- References: <200909022245.51969.stefan@codeweavers.com>
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