Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32

[Patrick Marlier <patrick dot marlier at gmail dot com>]

On 01/18/2012 02:26 PM, Uros Bizjak wrote:
> Hello!
>
> Attached three-liner patch fixes the declaration of BUILT_IN_TM_START
> (AKA _ITM_beginTransaction) to match its declaration from the libitm.h
> ABI. This mismatch was the core problem for FAILed
> libitm.c/mem(cpy|set)-1.c execution tests on x86_32.  Following that
> change, we need to teach _ITM_beginTransaction where to find its first
> argument, so it can be passed to GTM_begin_transaction.
>
> There was some discussion on where to pass arguments to regparm
> decorated vararg functions. Well, as the ABI is pretty clear - regparm
> should be ignored in this case, so all function arguments have to be
> passed in memory, even if that means that the value is kicked to the
> memory before the call, and pulled back into the register in
> _ITM_beginTransaction.
>
> 2012-01-18  Uros Bizjak<ubizjak@gmail.com>
>
> 	PR libitm/51830
> 	* builtin-types.def (BT_FN_UINT_UINT_VAR): New.
> 	* gtm-builtins.def (BUILT_IN_TM_START): Declare as BT_FN_UINT_UINT_VAR.
>
> libitm/ChangeLog:
>
> 2012-01-18  Uros Bizjak<ubizjak@gmail.com>
>
> 	PR libitm/51830
> 	* config/x86/sjlj.S (_ITM_beginTransaction) [!__x86_64__]: Load
> 	the first function argument to %eax.
>
> The patch touches generic libitm part, so I have tested it on
> i686-pc-linux-gnu (where it fixes all failures), x86_64-pc-linux-gnu
> and alphaev68-pc-linux-gnu.
>
> OK for mainline?
>
> Uros.

My main concern here is performance... Indeed, in case of libitm using 
Hardware Transactional Memory, it could be great to use registers for 
parameters. I would prefer to remove the variadic function as proposed here:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01784.html

As Torvald wrote, it was in case for hypothetical future parameters. So 
I would agree to do:
extern uint32_t _ITM_beginTransaction(uint32_t,uint32_t) ITM_REGPARM;

At least, it provides a new parameter for future use and do not use the 
stack for parameters.

Other thoughts?

Thanks.
--
Patrick Marlier.